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ABSTRACT 


The  INTEL  432/670  ffllerocomputer  lystem  contains  the 
lAPX-432  mlereproeessor  which  executes  compiled  ADA 
proorams.  The  compiler  resides  on  a  host  VAX  11/780^  and 
compiled  proorams  are  downloaded  to  an  INTEL  mds  800  system 
where  they  are  transferred  to  the  432/670  for  execution. 
This  thesis  describes  a  preliminary  performance  evaluation 
of  the  INTEL  432/670  through  the  use  of  selected  benchmaric 
algorithms  from  the  Computer  Family  Architecture  (CFA) 
study*  A  description  of  the  hardware  components  of  both  the 
NDS  800  and  432/670  is  provided,  including  the  modifications 
made  to  the  operating  system  to  allow  compatibility  with 
existing  hardware.  Additionally,  the  benchmaric  program 
source  code  and  a  user's  manual  are  appended. 
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A.  THESIS  DESCRIPTION 

Th«  dsvalopntnt  of  now  onolnoorlnq  tools  is  oeconpanled 
by  the  perceived  need  to  find  apolications  for  those  tools. 
Microprocessors  are  no  exception.  When  a  new  computer  is 
introduced  it  is  important  to  Know  what,  if  any,  sianiticant 
benefits  can  be  realized  through  its  use.  Things  to  consider 
in  evaluating  a  microprocessor  include  several  quantitative 
items,  such  as,  instruction  execution  speed,  memory 
capacity,  and  overall  performance.  Less  tangible,  but 
equally  important  qualities  of  multiprocessor  support,  user 
protection,  and  ease  of  programming  also  need  to  be 
measured.  The  introduction  of  the  INTEL  iAPX*432  in  1981 
represented  a  radical  change  from  traditional  computer 
architectures.  Previous  advances  in  Integrated  circuits 
have  primarily  focused  on  larger  memory,  and  faster 
execution.  The  iAPX-432  has  addressed  these  issues,  but  has 
also  tackled  many  of  the  problems  found  in  software 
engineering. 

This  thesis  Involved  the  setup  and  evaluation  of  a 
modified  INTEL  432/670  cress  development  system  to  measure 
the  overall  performance  of  the  programming  language  ADA 
executing  on  a  comeanion  vehicle,  the  INTEL  iAPX-432 
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nlerdproetifor.  Th«  motivation  for  this  investigation  was 
straightforward*  since  the  Department  of  Defense  has  «pent 
considerable  time  and  effort  In  developing  the  ADA  language 
It  would  be  Interesting  to  observe  hew  the  language  performs 
on  a  processor  that  was  designed  with  Identical  goals.  Zt  Is 
net  often  that  a  language  and  processor  are  developed  In 
parallel.  More  Importantly,  the  INTEL  lAPX-432's  unique 
architecture  directly  supports  many  of  the  Important  ADA 
language  features.  Such  as: 

1.  Access  protection  for  pacicages. 

2.  Automatic  maintenance  of  activation  record  stacics. 

3.  Multiprocessor  support  for  multltasKlng. 

This  support  mav  provide  for  less  expensive,  easier  to 
maintain  software,  a  common  objective  of  both  hardware  and 
software  designers. 

B.  EVALUATION  OF  COMPUTER  ARCHITECTURES 

Evaluation  of  computer  architectures  and  computer 
languages  has  traditionally  been  an  investigative  process 
directed  toward  a  specific  applleatlon.  This  study  Involved 
the  general  purpose  applicability  of  the  language  and  the 
processor.  The  choice  of  measurement  methods  used  followed 
an  earlier  effort  performed  by  the  Computer  Family 
Architecture  committee  in  1976  concerning  general  purpose 
computer  application  evaluations.  In  particular,  some  of  the 


btnehmaric  programs  usod  by  tha  eommlttae  wars  eodad  In  ADA 
and  than  axaeutad  and  timad  on  tha  iAPx-4a2.  Although  no 
provisions  nava  baan  mada  to  allminata  tha  effaets  o< 
eempllar  afflelaney,  or  Inaf flelaney,  tha  results  should 
give  an  indication  of  tha  axaeutlon  speed  available  to  tha 
and  user.  This  mathod  of  tasting  was  chosen  since  the 
processor  is  designed  to  be  prograirmed  In  a  high  level 
lanouaga  (ADA).  No  assembler  is  under  development  or  Planned 
for  by  the  manufacturer.  Therefore,  If  the  language  and 
processor  are  to  be  used  as  designed,  then  the  performance 
needs  to  be  evaluated  In  a  worXlng  environment.  That  Is, 
programmers  programming  in  ADA  and  compiled  code  executing 
on  the  processor. 

C.  THESIS  organization 

This  thesis  is  composed  of  six  chapters  and  five 
appendices.  Chapter  II  is  a  brief  discussion  of  the  woric 
done  by  the  Computer  Family  Architecture  committee  CCFA)  and 
it's  applicability  to  this  investigation.  Chapter  III  is  an 
introduction  to  soma  of  the  uninue  architectural  aspects  of 
the  lAPX-432  and  how  these  new  features  support  the  language 
ADA.  The  benchmaric  program  descriptions  and  timing  results 
are  in  Chapter  iv,  included  in  that  chapter  is  a  description 
of  tha  parameters  passed  and  the  calling  conventions  used. 
An  attempt  has  been  made  to  give  an  impartial  evaluation  of 
the  CDS  432/670  system  in  Chapter  v.  Finally,  in  Chapter  vi 


tht  reader  will  find  what  basic  conclusions  have  been  drawn 
about  the  1APX*432  and  the  CDS  432/670  system  as  a  result  of 
this  study.  The  appendices  are  filled  with  the  material 
necessary  to  repeat  any  of  the  results  obtained  In  Chapter 
XV.  They  Include  a  description  of  the  hardware  and  operatlnq 
system  modifications  performed  and  a  ilstlno  of  all  the  ADA 
source  code.  As  a  convenient  reference  the  alqorlthms  used 
by  the  CPA  are  provided  In  Appendix  D,  A  users  manual  Is 
Included  In  Appendix  E  to  allow  a  new  user  to  qulclcly  become 
familiar  with  the  system. 


II.  THE  MILITARY  gnWPtlTER  riMTLY  ARCHITgCTURE 

The  Military  Conputar  Family  Arehitaetura  (MCF)  rafars 
to  tha  arehitaetura  standard  defined  In  a  study  done  by  the 
Computer  Family  Arehitaetura  eommlttea  (CFA)  batwaan  Oetobar 
of  1975  and  August  of  1976.  Tha  Initial  study  concluded  that 
the  PDP-11  bast  mat  tha  criteria  for  a  military  computer 
family  standard.  Since  that  time  another  CFA  related  study 
by  Dlatztl]  suggested  several  improvements  In  the  algorithms 
used  to  evaluate  architectures.  An  overview  of  the  CFA 
project  follows. 

A.  CFA/MCF  PROJECT  MOTIVATION 

The  CFA/MCF  project  was  a  joint  ARMY/NAVY  effort  to 
develop  a  method  of  comparing  computer  architectures  for  use 
on  a  general  class  of  applications.  The  enormous  sums  of 
money  that  the  Department  of  Defense  was  spending  on  data 
processing  promoted  the  Investigation  Into  the  possibility 
of  defining  a  standard  computer  architecture. Decreasing  the 
life  cycle  costs  of  computer  systems  played  a  major  role  In 
the  committees  selection  criteria. 

B.  CFA/MCF  PROJECT  DESCRIPTION 

One  of  the  first  Items  the  CFA  examined  was  the  reason 
for  sicyroclcetlng  data  Processing  costs.  The  answers  they 
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obtained  were  net  too  surprising.  That  is,  eonputer 
selections  often  are  based  on  local  sehedulesr  funding,  and 
profit  considerations  with  little  regard  for  the  impact 
these  decisions  have  on  long  tern  hardware/software 
logistics  costs.  Consequently,  incompatible  military  systems 
are  contributing  to  the  problems  of  development  and 
maintenance  of  software.  Although  a  formal  movement  in 
standardizing  a  language  was  underway  (ADA),  there  was  no 
method  for  standardizing  an  architecture,  it  was  with  this 
mandate  that  the  CPA  committee  pursued  the  evaluation  of 
several  available  computer  architectures,  with  the  goal  of 
selecting  a  standard. 

A  standard  architecture  does  not  mean  specific  numbers 
of  registers,  accumulators  etc.,  but  rather  the  structure  of 
the  machine  that  a  programmer  needs  to  icnow  to  write  his 
programs,  for  example,  if  the  architecture  standard  requires 
stack  relative  addressing,  then  any  machine  having  that 
instruction  (and  the  other  required  instructions i )  can  be 
programmed  by  a  given  programmer  without  his  having  any 
knowledge  of  how  the  instruction  is  Implemented,  The 
programmer  knows  there's  a  stack  and  a  stack  relative 
address  instruction;  the  hardware  implementation  is 
transparent  to  him,  Zn  this  fashion,  any  two  computers 
having  the  standard  architecture  can  run  the  same  software. 
The  advantage  realized  is  that  new  hardware  with  faster. 


mor*  tffleitnt  physical  characteristics,  can  run  the  same 
software  with  little  or  ho  modification. 


C.  CPA  SELECTION  CRITERIA 

The  CPA  committee  initiated  the  selection  process  by 
speclfylnq  nine  absolute  qualitative  criteria  and  several 
quantitative  criteria  that  they  felt  an  architecture  must 
satisfy  to  meet  the  needs  of  a  military  computer  system. 

1 .  Qualitative  Criteria 

The  nine  qualitative  criteria  were: 


1.  Virtual  Memory  :  The  architecture  must  support  a 
virtual  address  to  physical  address  translation 
mechanism. 

2.  Protection  i  The  capability  must  exist  to  add  new 

experimental  programs  without  endangering  the 
liable  operation  of  existing  programs.  Architec¬ 
tures  with  orlvlleqed  modes  of  operation 

generally  meet  this  criteria. 

3.  Floating  point  Operations  s  The  explicit  support 
of  floating  point  data  types  with  more  than  10 
decimal  digits  of  significance. 

4.  Interrupts  and  Traps  :  The  capability  to  write  a 
trao  handler  to  respond  to  any  trap  condition 
with  the  program  resuming  operation  of  the  pro¬ 
gram.  Additionally,  the  architecture  needs  to  be 
capable  of  resuming  execution  following  any  in¬ 
terrupt. 

5.  Subsettablllty  :  Some  of  the  components  of  the 
architecture  must  be  able  to  be  factored  out  of 
the  full  architecture. 

6.  Multiprocessing  :  Support  of  communication  and 
synchronization  of  multiple  processors. 

7.  I/O  Controllability  t  A  processor  must  have  the 
ability  to  exercise  absolute  control  over  any  I/O 
processor. 
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8.  Exttnilblllty  I  Soffl«  method  needs  to  exist  to  add 
new  instructions  to  the  architecture  consistent 
with  existing  foroats. 

9.  Read  Only  Code  s  Zt  must  be  possible  to  execute 
programs  from  read  only  memory. 

These  nine  criteria  were  definitely  subjective  in  nature  but 
did  provide  a  good  initial  screening  for  any  standard 
architecture  candidate,  i^lthough  the  study  was  done  before 
the  introduction  of  the  INTEL  iAPX*432«  most  of  the  criteria 
are  met  or  exceeded  by  the  lAPX-432  with  the  exception  of 
the  Interrupt  capability.  The  lAPX-432  has  no  hardware 
interrupt,  however,  it  is  designed  to  operate  with  an 
attached  processor  which  does  have  an  interrupt  capability. 

2,  Quan£it.ati.ve-C£l.teriA 

The  guantltatlve  criteria  judged  by  the  CFA 
committee  included  the  following  items  t 

1.  virtual  address  space. 

2.  Physical  address  space, 

3.  Fraction  of  address  space  unassigned, 

4.  Nize  of  the  central  processor  state  (amount  of 
CPU  information  stored  on  interrupts). 

5.  Usage  base  (number  of  units  in  operation), 

6.  I/O  initiation  (efficiency  of  peripheral  device 
accessibility) . 

7.  virtualizability  (support  of  virtual  machines). 

8.  Direct  instruction  addressability. 


IS 


9.  M«xlnum  Interrupt  latency  (time  from  receipt  of 
Interrupt  to  processlnq). 

0.  MEASUREMENT  PARAMETERS 

The  quantitative  criteria  were  evaluated.  In  part,  by 
the  uae  of  twelve  benchaaric  programs.  These  programs  were 
hand  assembled  by  several  different  programmers,  and  then 
statistically  analyzed  for  program  use  of  computer  soace  and 
time.  The  measurement  parameters  used  ware: 

St  Measure  of  space,  the  number  of  bytes  used  to 
represent  a  test  program. 

Ml  Measure  of  execution  time,  the  number  of  bytes 

transferred  between  primary  memory  and  the  processor 

during  execution  of  the  test  program. 

• 

Ri  The  number  of  bytes  transferred  among  internal 
registers  of  the  processor  during  execution  of  the 
test  program. 

Although  the  S,m,  and  R  measures  are  useful  In 
evaluating  conventional  architectures,  they  are  not  readily 
applied  to  the  INTEL  1APX*432.  In  fact,  the  microprocessor's 
manufacturer  has  stated  that  there  Is  no  Intention  of 
supplying  an  assembler,  nor  Is  one  under  development.  This 
would  make  the  measurement  of  S  and  M  difficult  and  the 
measurement  of  R  virtually  impossible.  For  this  reason,  the 
evaluation  of  the  INTEL  1APX«432  was  primarily  based  on  the 
execution  timing  of  selected  benchmark  programs. 
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e.  BENCHMARK  EVALUATION  DESCRIPTION 

The  original  CFA  eomalttee  developed  twelve  beneheeric 
prootNiBS  to  evaluate  the  selected  criteria,  a  brief 
description  of  the  proqrams  fellows  with  a  complete 
alqerithmlc  description  in  Appendix  0, 

t,  I/O  kernel,  four  priority  level  Interrupts. 

2.  I/O  kernel,  FIFO  orocesslnq. 

3.  I/O  device  handler* 

4.  Large  fast  Fourier  transform  of  a  large  vector. 

5.  Character  search. 

6.  Bit  test!  set,  or  reset. 

7.  Runge-Kutta  Integration. 

8.  Linked  list  insertion. 

9.  Quicksort. 

10.  ASCII  to  floating  point  conversion. 

11.  Boolean  matrix  transpose. 

12.  virtual  memory  space  exchange. 

These  programs  tested  many  of  the  Items  considered  to  be  of 
value  by  the  CFA  committee,  however,  a  later  study  by  Dietz 
Cl]  determined  that  the  number  and  types  of  test  programs 
should  be  expanded.  The  proposed  set  of  benchmark  orograms 
consisted  of  sixteen  programs  organized  into  four  groups  as 


followsi 


A,  Inttrrupti  and  trap*. 

1.  Tarmlnal  Input  drlvar. 

2.  Mcssaoa  buffarlnd  and  transmission. 

3.  Multiple  priority  interrupt  handler. 

4.  virtual  memory  exchanoe. 

B.  Miscellaneous. 

5.  Scale  vector  display. 

5.  Array  iranloulation-LU  decomposition. 

7,  Target  traeXinq, 

4.  Digital  communications  processing. 

C.  Address  manipulation. 

9.  Hash  table  search. 

10.  Llniced  list  insertion. 

11 .  Presort. ^ 

12.  Autocorrelate, 

D,  Character  and  bit  manipulation, 

13.  Character  search, 

14.  Boolean  matrix  transpose. 

15.  Record  unpacKlng, 

16.  Vector  to  scan  line  conversion, 

A  complete  algorithmic  description  of  these  benchmark 
programs  can  also  be  found  In  Appendix  D. 

These  sixteen  algorithms  were  thought  to  more  rigorously 
test  specific  features  of  the  computer  family  architecture 
standard.  None  of  the  above  benchmarie  programs  are 
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neectf«rliy  firm  algorithms  that  must  ba  adharad  to. 
Hemavar.  thay  do  provide  soma  guldanea  In  tha  typa  of  tastes 
that  must  ba  parformad  by  a  eomputar  in  ordar  for  It  to 
fulfill  tha  iBlnlaun  raqulramants  of  an  arehltaetural 
standard.  Zn  tha  original  evaluation  the  PDP-11  was 
selected  as  tha  bast  candidate  arehltactura  for  the  military 
computer  family.  Since  that  time  several  ma^or  advances  In 
both  hardware  and  software  have  occurred.  The  unique 
architecture  of  the  INTEL  lAPX-432  provides  a  different  test 
Platform  for  the  execution  of  the  benchmaric  programs.  Those 
Droqrams  which  were  supeorted  by  the  current  INTEL  ADA-432 
eompllar  were  coded,  executed,  and  timed.  The  results  are 
summarlxad  in  Chaoter  iv  of  this  thesis. 
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III. 


THE  INTgL  lAPX-432  MICRQPRQCESSQR 


A.  ARCHITECTURE  DESCRIPTION 

Computer  arehiteetures  in  the  majority  of  commercial 
lystema  available  today  can  be  viewed  as  refined  descendants 
of  the  often  termed  Von  Neumann  computer  architecture#  A 
Von  Neumann  computer  architecture  usually  Includes  the 
feiiowlno  prooerties  C2] : 

1.  A  single#  sequentially  addressed  memory  which 
contains  both  prooram  and  data. 

2.  No  explicit  distinctions  between  instructions  and 
data.  Rather#  instructions  and  data  are  dls* 
tlnouished  by  the  ooeratlons  directed  towards 
tnem. 

In  1981#  Intel  announced  a  32»blt  VLSI  microprocessor 
incorporating  several  architectural  innovations  C3].  This 
announcement  stated: 


"The  Intel  lAPX  432  represents  a  dramatic  advance  in 
computer  architecture:  it  is  the  first  computer 
whose  architecture  supports  true  software  tran¬ 
sparent#  multiprocessor  operation;  it  is  the  first 
commercial  system  to  supeort  an  object-oriented 
programming  methodology;  it  is  designed  to  be 
programmed  entirely  in  high-level  languages;  it 
supports  a  virtual  address  space  in  excess  of 
a  trillion  bytes;  and  it  supports  on  the  chio  itself 
the  proposed  IEEE-standard  for  floating  point  arith¬ 
metic," 
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The  next  few  peges  will  be  devoted  to  providing  a  brief 
overview  of  the  following  architectural  aspects  of  the 
lAPX-4321 

1.  Object-Orientation. 

2.  Transparent  Multiprocessing. 

3.  Capability-Based  Protection. 

4.  Operating  System  Suoport. 

1.  Qbjeet^Qrtantatlfln 

What  does  It  mean  to  be  an  object-based  computer? 
Unlike  the  classical  Von  Neumann  architecture  described  In 
the  Introduction,  memory  Is  not  accessed  as  a  single, 
contiguous  block.  Rather,  the  memory  Is  considered  as  a 
collection  or  set  of  smaller  units  called  objects,  each  of 
which  occupies  some  contiguous  amount  of  memory,  very 
important  and  fundamental  to  this  concept  Is  the  object's 
recognition.  This  can  occur  In  software,  or  as  In  the 
majority  of  cases  for  the  432,  in  hardware.  This  recognition 
enables  the  object  to  be  typed  or  classified  as  to  the 
operators  which  are  allowed  to  act  uoon  the  particular 
object.  since  the  432  architecture  can  determine  the 
classification  of  an  object  It  can  prevent  Incidents  such  as 
Instructions  (e.g.  Instruction  objects)  being  Interpreted  as 
data,  and  conversely,  data  (e.g.  data  objects)  being 
executed  as  Instructions. 
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kt  the  machine  level#  objects  can  be  thou9ht  of  as 
being  segments#  a  segment  being  a  set  of  contiguous  memory 
locations  which  In  the  432  case  can  range  from  1  to  65# 536 
bytes  In  length.  However*  there  can  be  some  differences  In 
the  432  case.  Specifically#  an  object  can  be  any  one  of  the 
following: 

1.  A  single  segment. 

2.  A  collection  of  segments. 

3.  A  part  of  a  segment. 

This  latitude  in  object  abstraction  gives  compiler  designers 
a  powerful  base  on  which  to  build  object  oriented  compilers 
(ADA). 

Intel  has  moved  the  recognition  of  specific  object 
types  into  the  432  hardware#  as  alluded  to  above. 
Additionally#  certain  operators  on  these  objects  are 
incorporated  directly  Into  hardware,  while  other  ope' atlons 
must  be  done  via  software.  The  net  effect  of  this  decision 
Is  twofold: 

1.  Increased  reliability  of  all  operations. 

2.  Increased  execution  speed  of  certain  functions. 

Figure  1  Illustrates  some  typical  lAPX-432  hardware 


recognized  objects: 


Th«  Incorporation  of  an  object-based  proorammlng 
methodology^  in  the  manufacture's  own  words,  "...raises  the 
level  of  the  hardware/software  interface".  The  justification 
for  this  statement  can  be  found  in  the  following  example. 

Early  computers  had  very  simple  hardware  operations. 
These  early  machines  were  not  capable  of  supoorting 
f loatina-DOlnt  manipulations  directly.  Zf  you  wanted 
f loatlno-point  operations  you  had  to  implement  them  in 
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software.  with  the  passage  of  time  and  Increased 
technological  progress «  computer  hardware  gained 
functionality.  What  were  once  software  functions  found 
themselves  migrated  Into  hardware^  a  classic  example  being 
floating  point  operations.  This  evolution  of  software  Into 
hardware  Is  generally  regarded  as  raising  the  level  of  the 
hardware/software  Interface  In  a  computer  architecture.  The 
432  carries  this  progression  one  step  further  by  placing 
system  management  operations^  such  as  process  scheduling, 
memory  management,  and  Interprocess  communication  Into  the 
hardware  also.  Referring  bacic  to  Figure  l,  the  Importance  of 
such  objects  as  processor  object,  process  object,  etc. 
should  now  taiee  on  greater  slonlf Icance.  f^aturally,  more 
than  these  basic  system  objects  will  be  needed  to  Implement 
the  operations  listed  above.  The  processor  must  be  able  to 
manipulate  these  objects  In  an  appropriate  way  so  that  what 
Is  traditionally  done  in  a  series  of  prooram  steos  Is  now 
accomplished  with  a  single  Instruction.  The  net  effect  of 
such  hardware  instructions  Is  to  increase  processing  speeds. 

Recalling  the  example  of  floatlno  point  operations, 
we  find  that  their  Incorporation  into  hardware  increased 
their  speed  of  operation.  Furthermore,  soeed  and  reliability 
are  significantly  enhanced  when  an  operation  Is  Implemented 
in  hardware.  However,  the  capability  based  architecture  adds 
a  significant  amount  of  execution  time  to  each  Instruction 
and  conseguantly  the  performance  of  a  processor  Is  reduced. 
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The  choice  of  an  object-based  computer  architecture, 
besides  raising  the  hardware/software  Interface,  Integrates 
ideas  that  have  developed  over  the  last  decade  In  software 
engineering.  These  Include  data  abstraction,  domain  based 
orotectlon.  Information  hiding,  and  high-level  system 
functionality.  The  lAPX  432  is  an  attempt  to  bring  these 
notions  coherently  together  in  a  single  architecture. 

Summarizing,  an  object  can  be  regarded  as  possessing 
the  following  prooertles: 

1.  A  data  structure  that  contains  Information  in  an 
organized  manner. 

2.  A  set  of  basic  operations  may  manipulate  an  ob¬ 
ject,  The  432  hardware  ensures  that  these  are  the 
only  operations  that  can  manipulate  the  data 
structure, 

3.  An  object  can  be  addressed  as  a  single  entity. 

4*  An  Object  has  a  label  which  specifies  the 
object's  type  (e,g,  processor  vs,  process). 

Lastly,  as  regards  the  relationship  between  segments 
and  Objects,  a  segment  refers  to  the  physical  structure  of 
data  In  memory,  l.e,  where  the  structure  is  located.  An 
object  refers  to  the  logical  structure  of  data  In  memory, 
l.e.  how  the  memory  Is  used, 

2.  Transparent  Multlnroemgalng 

One  Of  the  most  highly  promoted  features  of  the 
lAPX-432  Is  Its  software  transparent  multiprocessing 
capabilities,  also  called  "incremental  computing  power". 
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What  this  naans  is  that  the  number  of  physical  processors 
CGDP  boards)  in  the  432/670  system  can  be  changed  without 
any  corresponding  changes  in  abplieatlon  software.  That  is, 
a  user's  application  program  never  has  to  be  concerned  with 
the  number  of  physical  processors  present.  The  only  visible 
effect  of  havlno  more  than  one  physical  processor  is  the 
increase  In  system  throughput.  This  iclnd  of  flexible 
performance  is  not  usually  associated  wltn  microcomputers. 
As  applications  become  more  complex  and  more  dynamic.  It 
becomes  Increasingly  difficult  to  predict  how  much 

processing  power  a  system  win  need  to  meet  Its  performance 
goals.  This  uncertainty  can  be  a  serious  source  of  rlsx.  An 
application  may  have  to  commit  itself  to  a  processor  some 
time  before  any  code  has  actually  been  written.  This  problem 
is  solved  by  the  lAPX-432  through  the  use  of  process- 
objects,  Processor  objects  are  abstractlc’-i-  of  nhysical 
processors  and  hence  their  behavior  can  be  manipulated  liice 
any  other  object. 

Transparent  multiprocessing  is  accomplished  through 
the  use  of  the  processor  object.  The  existence  of  a 

particular  physical  processor  is  Immaterial.  System 

throughput  can  be  Increased  by  adding  physical  processors 
(GDP  boards)  and  therefore  creating  more  processor  objects. 
More  processor  objects  means  that  more  user  processes  can 
execute.  Similarly,  the  removal  of  a  physical  processor 
results  in  the  removal  of  a  processor  object  and  a 
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subsequent  reduction  In  the  total  performance.  Fault 
tolerance  can  thus  be  said  to  be  improved  by  the  fact  that 
in  a  multiple  processor  environment.  If  a  processor  falls. 
It  Is  simply  removed  from  the  system.  The  only  effect  should 
be  some  reduction  In  throuqhput.  In  order  to  describe  how 
this  "software  transoarent"  multiprocessing  is  achieved, 
other  432  objects  besides  processor  objects  and  process 
objects,  will  be  Introduced,  Process  objects  can  be  equated 
with  user  programs  In  the  discussion  which  follows. 

The  term  dispatching  refers  to  the  assignment  of  a 
432  processor  to  some  process  which  Is  waltlno  to  execute, 
in  the  432  case,  this  Is  the  palrlnq*up  of  a  processor 
object  with  a  process  object.  The  manner  In  which  this  Is 
done  is  through  the  aid  of  another  particular  type  of  object 
called  a  dispatching  port  object,  since  this  Is  an  object, 
It  also  has  certain  unloue  operators  which  aoplv  to  It.  The 
dispatching  oort  object  can  be  thought  of  as  a  gueue-ll)ce 
data  structure  which  can  contain  process  objects  or 
processor  objects,  but  never  both.  Processors,  and  hence 
their  processor  objects,  are  self  dispatching  on  the  432. 
Therefore,  when  a  orocessor  completes  Its  current  tasic  or 
process  It  examines  the  dispatching  port  object  to  determine 
If  there  Is  a  waiting  process,  represented  by  a  process 
object,  enqueued  at  the  dispatching  port.  If  there  is  a 
process  object  present,  the  process  object  Is  "bound"  to  the 
orocessor  object,  that  Is,  a  llnK  Is  formed  between  the 
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processor  object  and  process  object.  The  processor  then 
dequeues  the  process  object  from  the  dispatchlnq  port,  and 
then  oroceeds  to  execute  the  process.  Conversely,  if  there 
are  no  processes  (process  objects)  enqueued  at  the 
dispatchlnq  port,  the  processor  enqueues  its  processor 
object  at  the  dispatchlnq  port,  in  effect  waitinq  for  the 
next  ready  process.  Processes  ere  not  dependent  on 
specifically  which  orocessor  Is  executino  It,  or  how  many 
processors  are  present  in  the  system.  Processes  ready  for 
execution  are  slmoly  enqueued  at  the  dispatchlnq  port.  The 
presence  of  more  physical  processors  simply  means  that  the 
averaqe  time  a  process  is  queued  up  at  a  dispatchlnq  port 
should  be  decreased, 

3.  Canabllltv  Baaed  Peateetton 

Sharlnq  data  amonq  a  computer  system's  users  in  a 
carefully  controlled  way  has  been  a  subject  for  much 
investioation  in  computer  systems.  Implementation  technioues 
aimed  at  provldinq  for  this  controlled  information  flow  have 
run  from  introduclnq  prlvileqed  and  user  Instructions  (e.q, 
IBM  360/370)  to  hierarchical  protection  systems  as 
classically  illustrated  In  the  nulTICS  rlno  structure. 
Intel's  approach  to  this  problem  in  the  432  architecture  has 
been  to  Implement  what  are  termed  capabilities. 

Capabilities  can  be  thouqht  of  as  tickets,  the 
possession  of  which  conveys  privileqes,  normally  the 
orlvileoe  to  access  a  seqment.  In  the  432  ease,  to  think  of 
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then  «s  a  pointer  plui  aeeeas  rlghti  pair  would  be  an  even 
eloaer  analogy.  Posaesalon  of  a  capability  means  that  access 
to  a  segment  is  allowed  under  the  access  rights  associated 
with  that  capability.  Access  rights  aret  read,  write,  both, 
or  neither.  In  order  to  ensure  protection,  certain  processes 
should  not  be  permitted  to  possess  capabilities  which  grant 
non^dlscrlmlnate  access  to  certain  oortlons  of  memory.  For 
example,  user  processes  should  not  have  access  to  the  memory 
where  the  operating  system  is  contained.  Therefore,  because 
of  their  function  and  inherent  potential  to  be  used 
maliciously,  capabilities  must  be  unforgeable.  In  the  lAPX- 
432.  capabilities  are  recognized  and  ooerated  on  by  hardware 
to  assure  this  needed  protection.  The  set  of  capabilities 
accessible  to  a  process  at  any  one  time  is  called  the  domain 
of  protection.  As  a  process  runs,  the  domain  of  protection 
will  change.  The  Ideal  to  be  realized  is  that  the  domain  of 
protection  should  always  be  exactly  matched  to  the 
requirements  of  the  process;  that  is.  It  should  contain 
capabilities  for  all  the  segments  that  the  process  needs  to 
access  and  nothing  more.  This  satisfies  the  principle  of 
'minimum  privilege'  In  secure  systems  Jargon, 

The  original  reasons  that  led  to  the  desire  to 
design  a  computer  with  a  capability  based  architecture  may 
be  summarized  under  ruggedness  and  security.  Ruggedness  In 
this  sense  means  the  ability  of  the  system  to  survive  the 
eenseouenees  of  hardware  failures  or  software  bugs  t41 . 
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security,  on  tno  othor  hand/  can  ba  thought  of  as  ensuring 
that  access  to  memory  Is  determined  exclusively  by  the 
access  rlohts  of  the  particular  process  In  question. 

There  are  basically  two  distinct  ways  of 
implementing  capabilities  In  hardware.  These  can  be  termed 
the  tagged  and  partitioned  approach  C51.  in  the  former,  all 
words  in  the  system  carry  a  'tag*  bit  which  olays  no  part 
other  than  to  indicate  whether  the  particular  word  Is  a 
capability  or  not.  in  the  partitioned  approach,  words  carry 
no  tag.  so  It  Is  not  possible  by  examining  a  word  In  memory 
to  determine  whether  It  Is  a  capability  or  data  word, 
instead,  the  type  of  segment  is  important,  l.e.  there  must 
be  capability  segments  which  contain  capabilities  and 
nothing  more,  and  'data'  segments  which  contain  anything  but 
capabilities.  The  lAPX  43T  uses  the  partitioned  approach. 

Intel's  decision  to  Imolement  the  partitioned 
approach  causes  us  to  slightly  refine  the  concept  of  an 
object  as  discussed  earlier.  As  was  previously  stated, 
objects  In  their  physical  form  are  equated  with  segraentCs). 
A  combination  of  an  object-based  architecture  with 
capabilities  Implemented  In  the  partitioned  approach  means 
that  each  object  Is  composed  of  two  distinct  parts,  a  data 
part  and  a  capability  part.  Indeed,  in  the  432  architecture 
there  are  two  fundamental  segment  base  types.  These  base 
types  are  called  data  segments  and  access  segments.  A  data 
segment  can  contain  anything  except  capabilities,  whereas  an 
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aeee«i  scqinant  can  contain  only  capabilities.  Therefore,  an 
object  should  now  be  correctly  envisioned  as  belnq  eonprlsed 
of  these  two  segment  types.  An  example  of  how  this  is 
actually  implemented  for  some  of  the  system  objects  is 
Shown  in  Figure  2. 


processor  object 
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Figure  2.  Object  Representation 


Summarizing,  Intel  has  implemented  capability  based 
support  for  memory  protection  in  the  432.  These  capabilities 
can  be  thought  of  as  an  address  of,  or  pointer  to,  an  object 
with  an  attached  type  describing  the  classification  of  the 
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rtfcrenctd  object  (e.q.  process  object*  context  object*etc.] 
end  «n  etteched  protection  mode  (e.g,  read  only  or 
reed/wrlte).  In  the  432*  Intel  has  decided  to  call 
capabilities  access  descriptors  because  of  their  similarity 
in  concept  to  pointer  implementation  in  ADA  which  is  termed 
an  'access*,  Purthermore*  objects  in  the  432  system  are  seen 
to  be  comprised  of  both  data  segmentCs)  and  capability 
(access  descriptor)  segmentCs).  The  data  segment  of  an 
object  could  be  thought  of  as  containing  information 
intrinsic  to  the  particular  type  of  object.  The  capability 
segment  on  the  other  hand*  contains  capabilities  for  all  the 
other  Objects  it  may  need  to  reference.  Additionally* 
capabilities  are  seen  to  enforce  the  principle  of  minimum 
privilege.  Perhaps  providing  an  Important  insight  into  432 
performance*  M.v,  wiDces  has  said  (6): 


"Compared  with  a  conventional  computer  system,  there 
will  inevitably  be  a  cost  to  be  met  in  providing  a 
system  in  which  the  domains  of  protection  are  small 
and  freouently  changed.  This  cost  will  manifest  it¬ 
self  in  terms  of  additional  hardware,  decreased 
run-time  soeed*  and  Increased  memory  occupancy.  It 
is  at  present  an  ooen  guestlor  whether,  by  the  adop¬ 
tion  of  the  capability  approach,  the  cost  can  be 
reduced  to  reasonable  proportions." 


4.  Oneratlna  System  Support 

Lixe  the  432  hardware*  Intel  has  created  an  object- 
oriented  operating  system  for  the  lAPX  432  called  IMAX.  It 
has  been  designed  as  a  multiprocessor  operating  system,  and 
conseouently  It  accommodates  any  number  of  running 
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proecsters.  As  a  re-sult*  all  synchronization  within  the 
system  must  be  explicit.  Furthermore,  as  the  manufacturer 
has  pointed  out  C7] .  the  432  and  IMAX  are  products  primarily 
intended  to  be  used  by  orlulnal  equipment  manufacturers  In 
the  construction  of  their  products.  Related  to  this  Is  the 
fact  that  IMAX  does  not  provide  a  command  language  or  a 
human  Interface,  rather  it  Is  designed  to  provide  executive 
services  to  user-provided  software  which  maxes  calls  to 
IMAX. 

Many  traditional  operating  system  primitives  are 
Implemented  as  hardware  functions  in  the  432.  In  an  effort 
to  elaborate  on  the  relationship  between  the  IMAX  operating 
system  and  the  Iapx-432  functions,  a  digression  Is  In  order. 
AS  pointed  out  earlier,  the  lAPX  432  architecture  provides  a 
higher  level  of  functionality  In  hardware  than  conventional 
computers.  Important  system  management  functions  are 
realized  through  hardware-recognized  representations,  l.e. 
objects.  High  level  operations  on  these  system  objects  (see 
Fig.  Cl}),  such  as  sending  a  message  between  processes,  are 
provided  as  single  machine  Instructions.  These  features  of 
the  432  are  referred  to  as  the  Silicon  Operating  system. 
These  features  are  not  In  themselves  an  operating  system, 
but  contribute  greatly  to  the  building  of  one. 

The  relationship  between  IMAX  and  the  hardware  might 
best  be  described  as  cooperation.  iMAX  doesn't  simply  run  on 
the  hardware,  rather  the  hardware  acts  autonomously  to 
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provide  Important  servleee*  such  as  processor  self- 
dispatching  as  pointed  out  earlier.  A  good  example  of  the 
division  of  labor  which  occurs  between  iMAX  and  the  432 
hardware  can  be  found  in  storage  management.  Hardware 
defines  system  objects  used  for  storage  management,  provides 
single  instructions  that  allocate  new  objects,  and  sets  flag 
bits  needed  for  storage  reclamation  and  virtual  storage 
management.  iMAX  will  then  provide  services  which  will 
create  and  reclaim  local  storage  pools  and  will  provide 
processes  which  compact  storage  and  reclaim  unreferenced 
objects. 

•  Probably  the  most  notable  point  about  iMAX  Is  that 
the  user  may  view  IMAX  as  a  set  of  ADA  oacicage 
specifications,  each  of  which  corresponds  to  a  particular 
service  provided  by  the  system.  Additionally,  there  is  no 
distinction  between  iMAX  oactcages  and  user-written  packages. 
IMAX  operations  and  user  operations  are  Invoiced  in  the  same 
way.  There  is  no  special  calling  convention,  no  'Supervisor 
Call'  instruction,  as  is  the  case  in  many  current  commercial 
systems.  The  effect  of  this  particular  implementation  is 
twofoldi 

1.  Users  can  create  subsets  of  IMAX  by  omitting 
unused  packages. 

2.  Users  can  create  supersets  of  iMAX  by  adding 
their  own  packages. 
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IMAX  «lso  benefits  from  the  432's  capability 
protection  machanism  described  earlier.  References  for 
system  objects  can  be  passed  to  user  processes  without  fear 
of  damage  or  system  compromise  because  the  rights  associated 
with  these  user  process  capabilities  have  been  modified  by 
IMAX  appropriately  (e.g.  read  only).  User  processes  cannot 
corrupt  these  references  passed  from  imax. 

Liice  the  432  hardware,  i.MAX  is  in  a  continual  state 
of  change  by  Intel.  Version  l.O,  which  this  thesis  woriced 
with,  is  a  preliminary  version  intended  to  get  potential 
users  qulcicly  acaualnted  with  it  in  order  to  acquire  the 
ability  to  execute  ADA  programs  on  the  432.  As  a  result,  the 
number  of  ADA  packages  which  the  user  can  tailor  to  his  or 
her  application  are  relatively  few.  As  advertised,  the 
following  services  are  provided  by  IMAX,  vi.O: 

1.  Configure  and  Initialize  a  multlple-GDP  system. 

2.  Read  from  and  write  to  the  debugger  console  ONLY. 

3.  Create  and  start  multiple  user  processes  defined 
at  compile  time. 

4.  Communicate  between  user  processes  by  exchanging 

messages . 

5.  Inspect  type,  rights,  and  storage  information 
contained  in  access  descriptors  and  object 
descriptors. 

6.  Inspect  context  and  process  dependent  information 
in  a  running  program's  environment. 
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Later  versions  are  supposed  to  support  Attached 
Processors  which  are  essentially  the  means  by  which  the  432 
can  communicate  with  the  outside  world.  When  this  support  is 
finally  implemented,  the  current,  severely  limited  i/o  Cl.e. 
debuooer  console  only)  will  be  replaced  by  a  variety  of 
conventional  I/O  devices. 

B.  AOA  LAMGUAGE  SUPPORT 

As  was  previously  mentioned,  there  was  a  considerable 
amount  of  parallel  development  between  the  ADA  lanpuaqe  and 
the  INTEL  lAPX-432.  Both  the  ADA  language  and  the  432 
architecture  address  many  of  the  problems  associated  with 
large  scale  software  development  projects.  This  resulted  In 
several  architectural  constructs  which  directly  support  many 
ADA  language  features, 

1 ,  nhlegr  Typing 

The  object  orientation  of  the  architecture  plays  a 
major  role  In  language  support.  Every  object  is  typed  by 
Che  compiler  or  by  the  hardware  to  indicate  Its  intended 
use.  This  allows  a  natural  separation  of  orocedure  objects 
from  data  objects.  In  addition  to  'intended  use'  typing,  the 
objects  are  also  classified  as  to  their  Internal  structure. 
This  structure  can  be  one  of  two  types,  access  objects  or 
data  objects.  The  access  object  Is  an  array  of  access 
descriptors  (to  other  objects)  while  data  objects  are 
structured  blocks  of  data  information.  Access  objects 
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contain  only  aeeest  descriptors  and  data  objects  contain 
only  data.  This  is  represented  in  Figure  3. 
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««*«« 

Figure  3,  AOA-432  Object  Types 


As  Shown  in  Figure  3.  any  set  of  iAPX»432  objects  can  be 
represented  by  a  directed  graph  containing  access  object 
nodes  and  data  object  nodes.  This  notatlonal  convention 
serves  as  a  useful  model  for  representing  execution  time 
objects  and  their  relationships  to  corresponding  ADA 
programs.  It  is  Important  to  realize  that  an  object  can 
exist  as  the  subpart  of  another  oject  and  yet  be  logically 
different,  such  an  object  that  is  ohysically  contained 
inside  a  parent  object  is  termed  a  refinement  of  the  parent 
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object.  The  refined  objects  are  physically  sub-parts  of  the 
parent  object,  yet  they  can  Inherit  the  full  privileges  of 
objects,  as  if  they  were  physically  distinct  fron  the 
parent.  Zn  the  case  of  multiple  refinements,  they  can  behave 
as  if  physically  distinct  from  other  refinements  of  the 
parent.  This  is  Illustrated  in  Figure  4. 


parent 

I— -f  I— -I 

II  ->  I  I  Child 

I  mmmm I 


I 

V 
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Figure  4,  Refinements 


2.  Domain  Obleets  -  Paelcaoe  Qbleets 

Common  data  structures  and  procedures  can  be  grouped 
together  using  the  ADA  oacicage  construct.  The  INTEL  lAPX-432 
uses  a  domain  object  to  represent  an  ADA  pacicage.  The  domain 
object,  nice  a  paelcaoe.  Is  a  collection  of  data  objects  and 
procedure  objects  (hence  It  is  of  type  access).  This  can 
best  be  Illustrated  by  the  following  example  of  an  ADA 
pacicage  definition  and  the  corresponding  lAPX-432  object 
representation  shown  In  Figure  5. 
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11/ jrki 

1  Proc .  1 

1 

Proc.  1 

end  ADD; 

IData  1 

1  ADD  1 

1 

SUB  1 

1  code i 

1  code  1 

» 

code  1 

1— —  1 

1 ......  1 

1  • 

1 

1 

1 

1 

1 

procedure  SUBTRACTCi, 
begin 

^  eg  1 *  ^  f 

end  SUBTRACT; 

end  SIMPLE; 

j/k)  is 

Figure  5,  ada  Paeicaae  and  Iapx«432 
Object  Correspondence 


Since  objects  can  be  refined^  it  is  possible  to  refine  a 
domain  object  to  create  domains  of  a  pacicage  with  different 
access  riohts.  This  mechanism  very  nicely  supports  the 
public  and  private  access  rights  defined  in  ADA.  A  user  is 
given  access  to  public  information  by  creating  a  refined 
object  with  access  descriptors  to  a  refined  domain  which 
contains  only  public  data. 

3.  Praeadura  Qbieets  »  Procedures 

An  iAPX-432  procedure  object  consists  of  executable 
code  corresponding  to  an  ADA  procedure.  The  procedure  object 
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also  contains  information  raquirad  to  form  the  activation 
record  or  context  object  which  Is  created  on  procedure 
invocation.  Procedures  may  be  invoiced  in  either  interdomain 
or  intradomain  contexts.  The  interdomain  context  means  that 
a  procedure  in  one  pacicage  (domain)  is  calllna  a  procedure 
in  another  pacicage  (domain).  Intradomain  procedure  calls  are 
simply  calls  within  the  same  pacicage. 

4.  Actlvailoru  Recards 

A  blocic  structured  language  such  as  AOA  can  maice 
efficient  use  of  activation  records.  The  iAPX-432  supports 
the  use  of  activation  records  via  context  access  objects  and 
context  data  objects.  The  context  access  object  represents 
local  reference  variables  and  the  context  data  object 
represents  local  data  variables  of  the  activation  record. 
The  lAPX-432  instructions  'procedure  call'  and  'procedure 
return'  create  and  destroy  context  objects, 

5.  Taa.taM 

one  of  the  important  multiprocessing  features  of  the 
AOA  language  is  the  concept  of  a  tasx.  Tasics  are  directly 
supported  in  the  lAPX-432  through  the  use  of  disoatching  and 
communication  port  objects.  The  communication  port  object  is 
a  laessage  queue  that  acts  as  a  buffer  between  processes  that 
may  be  executing  concurrently.  It's  function  is  to  allow 
inter-process  communication.  A  dispatching  port  is  a  special 
form  of  a  message  oueue  in  which  a  process  object  may  spend 
time  waiting  for  the  arrival  of  an  available  processor,  or 
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wh«r«  «  proetsior  objaet  awaits  tha  arrival  of  a  procass. 
Thasa  oparatlons  ara  parfornad  In  hardware  which  allows  for 
vary  afflelant  coding  of  tha  ADA  taslclng  modal. 

It  may  ba  surmised  from  the  previous  discussion  that  the 
lanquage  AOA  and  tha  INTEL  lAPX-432  have  several  common 
foundations.  This  was  undoubtedly  intentional.  The 
microprocessor  is  designed  to  be  orogrammed  using  high  level 
languages  such  as  AOA  as  the  development  language.  No 
assembler  is  planned  or  under  development  by  the 


manufacturer 


IV 


A,  BENCHffARK  PROGRAMS 

The  benehmeric  programs  ware  obtained,  for  the  most  part, 
from  the  CPA  algorithms  referenced  In  Chapter  II,  Section  E 
"Berchmaric  Evaluation  Description" ,  Some  oroorams  from  a 
non*CPA  related  study  vere  also  used  so  that  an  objective 
timing  comparison  could  be  made  witn  other  processors. 

1 ,  Methods  Used 

The  proorams  were  ceded  in  ADA,  compiled  using  the 
INTEL  ADA-432  compiler  on  a  VAX  -  11/780  host  computer, 
linked  on  the  VAX  -  II/790  using  the  INTEL  432  linker,  and 
downloaded  to  a  floppy  disk  via  the  INTEL  asynchronous 
communications  link.  Execution  of  the  downloaded  object  code 
was  performed  using  the  INTEL  Debugger  and  Execution 
software  package  operating  on  a  INTEL  mds  System  800.  The 
INTEL  MDS  system  is  regulred  to  load  the  executable  code 
into  the  INTEL  432/670  system  for  execution  on  the  lAPX-432 
mlcroDroeessor.  The  system  setup  is  shown  Figure  6. 


VAX  11/700  VAX  11/780 


•  I  — >  I  J 

I  II  I 


compile  link 


MDS-800  432/670 


— >  I  I  •>  I  I 

III  I 


download  execute 


Figure  6.  COS  System  Overview 
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In  order  to  actively  elmulate  large  scale  software 
development  (and  to  exercise  some  unique  ADA  features)  all 
the  ceded  CFA  programs  were  developed  in  such  a  way  that  the 
program  specifications  were  separate  from  the  program  body. 
The  effect  of  this  decision  was  twofoidt 

1.  Programs  could  be  written  and  debugged  indepen¬ 
dently  by  both  authors. 

2.  The  concept  and  value  of  using  a  separate  program 
specification  construct  could  be  demonstrated. 

A  careful  inspection  of  each  benchmarx  program  will  reveal 
that  it  consists  of  three  primary  parts.  These  parts  are: 

1.  Paexage  specification. 

2.  Paexage  body. 

3.  Main  or  driver  procedure. 

The  driver  routine  Is  needed  to  initiate  a  user  process  in 
the  432/670  system.  The  programs  were  designed  so  that  the 
user  could  control  the  number  of  times  the  benchmarx  was 
invoked.  This  allowed  for  an  effective  averaging  method. 
For  example,  the  benchmark  could  be  executed  100. OOn  times, 
accurately  timed  with  a  stopwatch,  and  then  the  total 
elapsed  time  could  be  divided  by  100.000  to  obtain  the 
average  execution  time  for  the  procedure.  Each  program 
writes  a  start  and  a  stop  message,  including  an  audible 
'bell'  to  indicate  when  to  commence  and  end  timing.  In 
order  to  effectively  Isolate  the  procedure  invocation  timing 
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ovtrh«ad  from  the  benehmeric  timing^  there  were  usually  two 
different  driver  routines  with  each  benchnaric  program.  Each 
program,  when  executed,  would  request  the  number  of  times  to 
perform  the  algorithm  In  question.  This  request  could  come 
from  the  driver  routine  or  from  the  benchmaric  procedure.  If 
It  came  from  the  former  then  the  time  measured  Included  the 
time  required  to  Invoke  the  procedure,  a  timing  request  from 
the  benchmaric  procedure  Included  only  the  timing  required  to 
perform  the  algorithm.  The  difference  In  the  two  times  was 
then  a  measure  of  the  procedure  invocation  overhead.  Note 
that  this  method  would  not  work  with  a  recursive  procedure. 
Further  discussion  of  these  methods  and  the  mechanics 
involved  can  be  found  In  Chanter  V,  "CDS  432/670  User 
Evaluation, " , 

2.  APoltgabla  Alaorlthma 

The  AnA«432  compiler  (Version  1.0}  does  not  support 
the  full  ADA  language.  The  manufacturer  has  added  some 
extensions  to  the  compiler  but  It  presently  lacks  manv 
Important  ADA  features.  Some  of  the  significant  compiler 
limitations  are  as  fellows: 

1.  Fixed  point  and  floating  point  types  are  not  Im* 
plemented. 

2.  Tasking,  as  defined  In  the  Reference  Manual  for 
the  ADA  Programming  Language,  is  not  Implemented, 

3.  Array  operations,  such  as  concatenation,  assign¬ 
ment.  and  boolean  operations  are  not  Implemented, 
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4.  Dyntmle  arrays  and  dynamle  strings  are  not  Imple¬ 
mented, 

5.  Pun  time  ehecics  are  not  operational. 

6.  Exceptions  are  not  Implemented. 

7.  Record  representations  for  records  containing 
fields  of  type  access  are  not  implemented. 

Although  the  above  compiler  limitations  are  rather  severe  it 
■MBS  Still  Possible  to  code  several  of  t^e  CF&  algorithms  In 
AOA-432  and  most  of  those  coded  could  oe  executed  on  the 
lAPX-432.  The  lack  of  a  hardware  interrupt  orevented  many  of 
the  CFA  benchmarks  from  being  coded.  Future  releases  of  the 
432/670  system  are  supposed  to  provide  the  facility  of  an 
interrupt  through  the  use  of  an  attached  processor.  This 
feature  was  not  available  In  this  release  of  the  432.  A 
short  description  of  each  of  the  executable  oroorams 
follows.  The  complete  source  code  can  be  found  In  Appendix 
C. 

a.  Character  Search 

This  Program  searched  a  given  string  for  the 
occurrence  of  an  argument  string  and  returned  the  location 
of  the  argument  string.  If  It  was  located.  The  program  was 
coded  from  the  algorithm  In  the  original  CFA  study.  The 
algorithm  la  listed  in  Appendix  D.  The  strings  were  read 
into  a  variable  of  type  STRING80.  which  Is  an  ADA-432 
predefined  type  regulred  for  text  I/O.  The  strings  were 
then  decomposed  into  Individual  characters  and  assigned  to  a 
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1  by  256  eh«raeter  array.  This  aatbod  was  naeassary  baeausa 
of  tha  prlnltlva  stata  of  tha  currant  ADA*432  taxt  1/0 
paelca^a.  Tha  program  mada  Intaraetlva  to  allow  for  many 
saarehas  to  ba  parformad  in  any  givan  debugglno/exaeution 
sasalon.  Tna  data  strueturas,  calling  convantions,  and  a 
sampla  expactad  result  ara  shown  In  Figure  7. 
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Figure  7.  Character  Search 
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Two  vorslens  of  the  program  were  used.  One 
version  included  the  time  required  to  invoke  a  procedure 
while  the  ether  version  did  not  Include  procedure  Invocation 
overhead.  As  will  be  shown  In  the  timing  results  section  of 
this  chapter,  procedure  invocation  Is  expensive. 


b.  Quicksort 

This  program  performed  a  quicksort  on  a  given 


array  of 

records. 

The 

program  was 

coded  using 

the  CFA 

quicksort 

algorithm 

In 

Appendix  D. 

The  records 

sorted 

consisted  of  an  Integer  key  field  (to  be  sorted  on)  and  a 
character  field  associated  with  each  key.  A  pictorial 
representation  of  the  data  structure  and  the  sorting  process 
and  calling  convention  Is  shown  In  Figure  9. 
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The  program  was  written  to  act  interactively  with  the  user 
to  allow  for  several  different  runs  per  debugging  session. 
Two  versions  of  Ouielcsort  were  used,  one  was  an  iterative 
sort,  the  other  a  recursive  sort.  The  timing  results  show 
that  the  procedure  invocation  overhead  of  the  recursive  sort 
was  significant. 

c.  Hashtable 

This  program  located  the  position  a  key  would 
occupy  in  a  hash  table.  An  example  of  the  data  structure 
used  and  the  calling  conventions  are  shown  in  Figure  9.  The 
algorithm  for  this  program  was  obtained  from  the  second  CFA 
study  by  DietzCl]  and  can  be  found  In  Appendix  D. 


TABLE 

HASHESCkey)—  1— — . 

»  1 

(  1 

1 mmmmmm* 

1 

V  1 

1 

*  • 

1 

1 

1 

a  1 
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position  :«  HASHE8( 

key  ) 

Figure  9.  Hashtable  Data  structure 
and  Calling  Convention 


Since  this  program  used  a  function,  there  was  only  one 
version  written.  The  procedure  invocation  overhead  is 
included  in  the  timing  results. 
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d.  Diqltal  Cofflfflunleatlons  Processing 

This  program  sent  a  message  to  a  given  output 
buffer.  The  algorithm  was  taken  from  the  second  CFA  study  by 

I 

Dietz  [1]  and  Is  located  In  Appendix  D.  The  data  structures 
used  for  the  program  and  a  tyolcal  calling  convention  are 
shown  In  Figure  10. 
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Figure  10.  Digital  Communications 
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Th«  program  interaetlvaly  guarled  for  the  mesiage 
deatlnatlon^  message  connection  and  the  message  text.  This 
allowed  for  several  sample  runs  to  be  performed  during  a 
debugging  session. 

e.  Memory  Usage 

A  close  inspection  of  the  ADA  source  code  in 
Appendix  C  shows  that  many  of  the  data  structures  are  quite 
small.  This  Is  intentional,  and  necessary.  Early  In  the 
course  of  this  investigation  It  was  discovered  that  programs 
would  compile  correctly  but  execute  in  an  unpredictable 
manner.  The  problem  was  found  to  be  In  the  amount  of  heap 
memory  allotted  to  a  user  process  in  Version  1.0  of  the 
1MAX-A32  operating  system.  The  memory  allocated  was  not 
extremely  large,  and  could  often  be  used  up  without  any 
Indication  to  the  user  what  was  wrong.  The  program  Eat- 
Memory  was  written  to  demonstrate  how  fast  memory  was  used 
up.  The  program  was  fairly  simple  in  that  all  it  did  was  to 
create  an  array  of  90  characters  and  a  pointer  to  the  array. 
This  program  was  also  written  in  two  versions,  one  that 
created  the  arrays  recursively,  the  other  Iteratively.  The 
expense  of  context  creation  In  a  recursive  procedure  was 
shewn  to  be  very  great.  Only  nine  recursive  calls  could  be 
made  before  the  program  used  all  of  the  available  memory  and 
the  system  crashed.  The  iterative  version  did  much  better 
and  igg  separate  data  structures  were  created  before  all 
available  memory  was  exhausted.  Of  particular  Interest  to 


50 


the  user  is  that  there  Is  no  indication  as  to  what  is  wrong 
when  the  menory  Is  used  up.  The  display  Is  "blanic"  and  all 
efforts  to  use  the  debug  facility  resulted  In  a  system 
response  of  *no  current  orocess".  In  summary »  the  user  must 
laboriously  Inspect  the  program  object  code  (the  map  file) 
and  arbitrarily  set  breakpoints  In  the  code  to  determine 
what  the  cause  of  the  fatal  error  is.  This  problem  is 
elaborated  In  Chaoter  V  of  this  thesis. 

3.  CFA  Coded  but  not  Eweeiifad  Programs 

Two  programs  from  the  first  CFA  study  were  coded  In 
ADA  and  executed  on  an  ADA-ED  compiler  to  checK  for  correct 
program  execution.  These  programs  were: 

1,  Llnxed  List  Insertion. 

2.  Runge-Kutta  Integration. 

Unfortunately  the  present  ADA-432  compiler  does  not  support 
the  floating  point  data  type  necessary  for  the  integration 
program;  nor  does  the  ADA-432  compiler  support  records  with 
access  types,  which  is  necessary  for  the  iinxed  list 
Insertion  program.  The  ADA  source  code  for  these  programs  Is 
located  In  Appendix  C  for  easy  reference  to  allow  for 
possible  conyerslon  when  a  more  complete  complinr  Is 
released. 

4.  Non-CFA  Related  Programs 

Since  the  CFA  study  never  actually  timed  the 
benchmark  programs  In  terms  of  execution  speed,  It  was 
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d«cld*d  that  a  physical  comparison  of  tha  lAPX-432  with 
othar  procassors  would  be  useful.  A  previous  evaluation  of 
the  lApx-432  by  Hansen  [3]  in  June  1982  provided  three 
convenient  AOA  programs  to  use.  These  programs  were  obtained 
from  the  Computer  science  Department  at  U.C.  Bericeiey. 
modified  slightly  to  conform  with  the  current  ADA>432 
compiler  requirements,  and  then  executed  and  timed  on  the 
432/670  system.  The  three  proorams  used  were: 

1.  Search:  Search  a  120  character  string  for  a  15 
character  sub-string. 

2.  Sieve:  Compute  prime  numbers. 

3.  Acleer:  calculate  Acicerman's  function  with  argu¬ 
ments  3  and  6.  This  is  a  recursive  computation 
reoulrlng  more  than  170,000  procedure  calls. 

The  complete  ADA  source  code  for  the  proorams  can  be  found 
In  Appendix  C,  The  timing  results  are  summarized  In  Chapter 
tv. 

B.  TIMING  PROCEDURE  AND  RESULTS 

All  the  CFA  programs  were  written  so  that  the  user  could 
write  the  arguments  from  the  keyboard  and  select  the  number 
of  times  the  program  was  to  execute.  Dividing  the  total 
elapsed  time  by  the  number  of  times  the  prooram  executed 
gave  an  average  value  of  execution  time  for  the  particular 
benchmark.  Procedure  Invocation  overhead  was  subtracted  from 
the  non-recurslve  procedures  and  both  timing  values  are 
shown  In  the  following  discussion,  in  addition,  the 
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p«r«n«tert  used  and  the  number  of  executions  are  also 
listed. 

1.  CFA  Benghmarte  Program  R*«ulta. 

The  following  sections  describe  the  parameters  used 
for  each  benchmark  executed,  the  number  of  executions 
performed,  the  total  elapsed  time  (in  seconds),  and  the 
calculated  execution  time  for  a  single  run.  Note  that  the 
program  name  corresponds  to  the  ADA-432  source  code  for  the 
respective  program  In  Appendix  C. 
a.  Character  Search 

The  parameters  used  In  this  benchmark  timing 

were: 

SEARCH  STRING  :  Monday.  June  7tn,  1976 
ARGUMENT  STRING  i  day 
SEARCH  LENGTH  t  22 
ARGUMENT  LENGTH  .*  3 


Program 

Number  of 

Elapsed  time 

Time 

name 

executions 

seconds 

msec 

CHARSl 

100.000 

315.6 

3.2 

CHARS2 

100.000 

142.3 

1.4 

Eldure  11.  Character  Search  Results  -I 
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Th«  program  CHARSl  Included  the  time  required  for  100,000 
procedure  Invocations  whereas  CHARS2  did  not.  For  this 
benchmaric,  Flqure  11  shows  that  the  procedure  overhead  was 
more  than  twice  the  time  to  perform  the  algorithm! 
b.  Qulclcaort 

Two  forms  of  the .  qulctcsort  algorithm  were  used, 
one  recursive  .  the  other  Iterative.  A  twenty  element  array 
was  sorted.  The  worst  case  array  was  chosen,  that  Is,  all 
the  elements  were  Inversely  ordered.  Figure  12  represents 
the  parameters  pasfed;  unsorted  arrayl  was  passed  to  the 
procedure  and  the  sorted  array2  resulted. 


arrayl  t 

20  19  10  17 

16  IS  14  13 

12 

11  10  9  8  7  6  5  4 

3  2  11 

array2  : 

12  3  4  5  6 

7  8  9  10  11 

12 

13  14  15  16  17  18 

19  20 

Program 

Number  of 

Elapsed  time 

Time 

name 

executions 

seconds 

msec 

OUTCKl 

(recursive) 

1000 

55.8 

.56 

QUICK2 

1000 

40.5 

.41 

(non  recursive) 

Figure  12.  Oulcicsort  Results 
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As  skpectsd,  the  recursive  procedure  tooic  considerably 
longer  to  execute.  This  Is  net  too  surprising  since  the 
overhead  of  procedure  Invocation  Is  Included, 
c.  Hashtable 

The  hashtable  algorithm  was  implemented  as  a 
function.  The  timing  results  therefore  include  the  function 
call  overhead.  This  function  used  the  sample  hash  table  from 
the  CFA  study  and  a  Key  value  of  41  was  used  as  the  argument 
of  the  function.  The  hashtable's  Initial  values,  calling 
convention,  and  timing  results  are  shown  in  Figure  13, 


Key 

1  0 

183  11 

1035 

1035 

183 

pdseis 

86 

■  aa« 

0 

183 

183  1 

index 

1 

1  0 

1  2 

3 

4 

5 

6 

7 

•  am 

8 

9  1 

position  :s  HASHES(41) 


Program 

Number  of 

Elapsed  time 

Time 

name 

executions 

seconds 

msec 

HASHl 

100,000 

252 

2,5 

Figure  13.  Hashtable  Results 


d.  Digital  Communication  Processing 

This  procedure  sent  a  thirty  character  message 
to  the  output  buffer.  Figure  14  represents  the  data  values 
passed  to  the  procedure  for  processing. 
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msQ.ptr  I  I 


1 .. ........ 1 ........  I ...............................  I 

I  10  I  10  I  This  Is  a  thirty  character  msal 

1 .. ........ 1 ........ 1 ...............................  I 

destination  connection  messaqe  data 


Program 

name 

Number  of 
executions 

Elapsed  time 
seconds 

Time 

msec 

DCOMl 

100,000 

286.9 

2.9 

0C0M2 

100,000 

201.6 

2.0 

rioure  14.  Digital  Communication  f>esults 


Zn  this  case  the  procedure  overhead  was  nearly  one  third 
that  of  oerformlna  the  alaorlthm. 

2.  Won  era  Program  Results 

An  earlier  study  of  the  432  was  performed  by 
Hansen C3]  at  U.C.  BerKeley.  Several  benchmark  programs  were 
coded  and  executed  on  various  machines  and  in  several 
different  languages.  A  summary  of  those  results  Is  shown  in 
Figure  is. 
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machine 

language  1 

program 

name 

Search  1 

Sieve 

AeXer 

432 

ADA  I 

14,2  i 

3200 

260#000 

4  MHZ 

1 

8086 

PASCAL  i 

7,3  i 

764 

11100 

5  MHZ 

1 

68000 

PASCAL  i 

1.3  i 

196 

2750 

16  MHZ 

1 

VAX 

PASCAL  1 

1.4  i 

259 

9800 

11/780 

(VHS)  1 

1 

1  1  All  times  are  In  msec 

These  results  are 

from  a  study  by 

HANSENC3] 

Which  were  performed  on  a  432  version  2.  The 

processors  manufacturers  were  t  8086  -  INTEL# 

68000  -  motorola# 

VAX  11/780  -  DEC. 

1 

Figure 

15,  Previous  Non  CFa 

Timing 

Results 

An  attempt  was  made  to  duplicate  the  results  fsom 
the  earlier  study  by  executinp  the  benchmarK  programs  on  the 
cns  432/670  system.  The  programs  that  were  received  from 
U.C,  BerKeley  would  not  compile  under  version  1.0  of  the 
compiler  supplied  with  the  432/670  system.  No  parameters 
were  passed  In  using  these  tests#  they  were  Included  in  the 
code.  An  examination  of  the  ADA  source  code  In  Apeendix  C 
will  also  reveal  that  no  effort  was  made  to  separate  program 
body  from  program  specification.  The  results  from  our 
timing  are  shown  In  Figure  16, 
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iR«ehlne 


Extrcff*  caution  must  be  exorcised  when  comparing  these 
values  to  the  previous  study.  Specifically  in  the  case  of 
the  SIEVE  and  ACKER  orograms.  The  limited  stacK  heap 
available  prevented  Implementing  the  code  exactly  as  done  by 
U,C,  Bericelcy.  The  results  of  the  SEARCH  benehmarK  are  very 
Interesting,  The  three  programs  received  from  u,c.  Berkeley 
required  seme  modification  before  they  would  compile 
successfully  on  the  Intel  AOA-432  compiler.  More 
Importantly,  our  results  generally  include  the  time  required 
for  procedure  invocation.  In  some  Instances,  notably  our 
algorithm  Implementing  the  character  search,  we  also  have 
results  which  do  not  Include  procedure  Invocation  overhead. 
Lastly,  whereas  we  used  the  concept  of  pacicages  In  arriving 
at  the  coding  of  our  benchmarKs,  the  U.C. Berkeley  programs 
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did  not,  Thos*  dlffcrencog  «ro  eaaliy  scon  by  referring  to 
Appendix  C. 

It  Is  not  clear  whether  the  results  by  HansenOl 
Include  procedure  Invocation  overhead.  However,  since  the 
432  used  In  this  thesis  had  a  S  MHZ  clock  rate  (with  an  8 
MHZ  system  clock)  as  opposed  to  a  4  mhZ  clock  riite  in  the 
Hansen  study,  one  would  suspect  that  running  the  same 
program  with  the  same  data  would  give  at  the  least, 
comparable  results.  To  our  surprise,  this  was  not  the  ease. 
Initially,  we  timed  the  SEARCH  algorithm  sent  from  Berkeley 
"as  is".  This  was  timed  at  23  milliseconds,  quite  a 
difference  from  14.2  In  the  previously  cited  study.  We  then 
modified  the  Berkeley  algorithm  so  as  not  to  Include  string 
initialization  each  time.  Since  our  first  timing  was  so 
different  from  the  Berkeley  study  we  thought  that  string 
Initialization  should  not  be  Included  In  the  results.  The 
second  test  was  made  by  just  timing  the  Berkeley  search 
function  alone.  This  Included  procedure  Invocation  overhead. 
The  result  is  listed  in  Figure  16. 

C.  SUMMARY  OF  RESULTS 

The  data  In  the  previous  figures  pertinent  to  the  CFA 
studies.  Is  summarized  in  Figure  17.  It  is  believed  by  the 
authors  that  the  following  times  represent  realistic 
execution  speeds  available  to  a  user  performing  In  the 
working  environment  of  the  present  432/670  system. 


Figure  17.  Execution  Speed  Result  Summary 


The  data  reported  above  does  not  include  the  procedure 
invocation  overhead,  with  the  exception  of  the  recursive 
QulcKsort  and  the  function  Hashtable  Loolcup.  It  needs  to  be 
emphasized  that  the  numbers  are  only  'rules  of  thumb'  that 
should  be  used  In  describing  the  execution  speed  of  the 
1APX-43T.  Compiler  differences,  and  just  as  Importantly  the 
argument  used  In  the  algorithm,  can  significantly  affect  the 
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•xccutlon  sp««d.  For  txanpl««  If  the  eheraeter  string 
saarehad  for  in  the  Character  Search  is  near  the  beginning 
of  the  search  string  vs.  near  the  end  of  the  search  string/ 
tha  results  can  vary  by  as  much  as  a  factor  of  ten.  (The 
length  of  the  string  searched  also  plays  a  significant  role 
in  determining  execution  time).  The  exact  arguments  passed 
and  the  calling  conventions  used  have  been  described  in 
detail  (Chapter  IV, S)  for  future  reference  and  comDarlson, 
The  values  in  Figure  17  represent  an  approximation  to 
the  time  required  to  perform  a  given  algorithm.  In  order  to 
cross  check  and  verify  the  timing  results,  an  effort  was 
made  to  time  a  single  iAPX-432  instruction.  This  was 
accomplished  by  writing  two  test  programs,  TlOO  and  TlOl, 
which  differed  by  a  single  line  of  source  code.  That  is, 
TlOO  executed  "A  :a  s  •  C*  one  hundred  times  and  TlOl 
executed  "A  ta  b  •  C”  one  hundred  and  one  times.  An 
examination  of  the  MAP  file  (the  compiler  output)  revealed 
that  the  code  differed  by  one  statement.  That  statement  was 
"sub.l",  an  iAPX-432  mnemonic  for  subtract  Integer,  The  time 
difference  between  the  two  programs  could  then  give  a  figure 
for  the  execution  speed  of  the  single  sub.i  instruction.  The 
measured  speed  could  be  directly  compared  with  a  previous 
study  C8]  which  timed  individual  instruction  speeds  on  a 
4MHZ  iAPX-432/100  Versionl,  The  results  are  summarized  in 


Figure  is 


Pro9raffl  Number  o<  tlmeCiec)  difference 
name  aub.l  executions 

........ I ................ I .......... I .......... 

TlOO  I  40,000,000  I  777.8  I 

........ I ................ I .......... I  .......... 

6.90 

........ I ................ I  .......... I .......... 

TlOl  I  40,400,000  I  784.7  I 

........ I ................ I  .......... I  .......... 

execution  time 

sub.l  a  6,90  /  400,000  a  1,73  X  10-5  sec 

sub.i  sub.l 

Version  1  SMHZ  version  2  5MHZ 

estimated  cycles  measured  cycles 

77  ’  86 


Estimated  cycles  are  from  an  earlier  study  C8} 
on  a  432/100  system  and  represent  a  projection 
based  on  measured  results.  Version  2  measured 
cycles  are  the  result  of  the  product  of  execution 
time  and  the  clocK  rate. 


Ploure  19.  Individual  Instruction  Timing 


As  can  be  seen  In  Figure  18,  the  measured  speed  of  the 
sub.l  instruction  in  this  study  is  in  good  agreement  with 
the  previous  results.  The  differences  can  possibly  be 
accounted  for  in  the  fact  that  two  different  versions  of  the 
microprocessor  are  being  compared. 

An  attempt  was  also  made  to  eliminate  the  effects  of 
"dead  time",  or  "time  out"  in  the  execution  of  a  brogram. 
This  time  out  is  the  oerlod  during  which  a  process  is 
suspended  while  the  dispatching  port  is  checked  for  another 
process  to  be  assigned  to  a  processor.  Normally  a  process  Is 


glvtn  a  datault  value  of  0.2  seconds  of  dedicated  processor 
time  between  time  outs.  Since  only  one  program  was  executing 
at  a  time/  it  was  not  believed  that  the  program  timing 
results  would  be  significantly  affected  by  the  dispatching 
pert  checle  overhead.  To  verify  this,  a  modification  was  made 
to  the  INTEL  supplied  ADA  pacicage  PSCRP.mbS.  The 
modification  increased  the  time  slice  from  0.2  seconds  to  2 
seconds.  Similar  oroorams  that  differed  only  in  the  time 
slice  period  (0.2  seconds  vs  2  seconds)  executed  within  0.5 
seconds  of  each  other  over  a  total  execution  time  of  200 
seconds.  This  confirmed  that  the  time  slice  period  between 
dispatching  pert  checlcs  was  not  significantly  interfering 
with  the  benchmark  results. 


V.  gps  USER  eVALUATIQN 

In  the  process  of  woriclna  on  tnii  thesis  both  authors 
felt  that  a  section  devoted  to  constructive  erltlelsn  of  the 
INTEL  Cross  Development  System  would  be  appropriate.  By 
Cross  Development  System  we  mean  the  INTEL  ADA  compiler, 
llnicer.  downloading  and  execution  software  and  corresoondlnc 
documentation.  Additionally  we  conclude  with  some  of  our 
thoughts  on  ADA.  We  understand  that  many  of  the  problems 
addres'ted  here  are  not  permanent,  and  very  llicely  many  of 
the  items  we  have  found  to  be  mysterious  or  IrKsome  may  have 
already  been  corrected  In  a  later  release. 

The  INTEL  432/670  system  can  be  conveniently  divided 
Into  four  major  components: 

1.  Compiler. 

2.  Linicer. 

3.  Downloading  and  Asynchronous  Communication. 

4.  Debugging  and  Execution. 

The  following  discussion  will  treat  each  component  in  turn, 
stating  what  positive  and  negative  attributes  we  found. 

A.  COMPILER 

The  ADA-432  compiler  does  net  support  full  ADA.  The 
language  limitations  are  listed  in  Chapter  IV.  Of  these,  the 
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lack  of  floating  point  number  support  was  fait  to  be 

extremely  burdensome  to  this  thesis,  a  great  many  of  the  CPA 

measures  are  focused  on  floating  point  manipulation,  as  are 

many  real  world  applications.  At  the  machine  level,  the 

lAPX-432  has  outstanding  floating  point  support,  such  as 

multiply,  divide,  and  square  root  machine  instructions.  The 

% 

lack  of  compiler  support  for  floating  point  operations 
prevented  us  from  testing  proorams  In  an  area  where  the 
lAPX-432  Should  provide  outstanding  performance. 

The  present  text  I/Q  package  provided  in  the  AOA-432 
compiler  can  best  be  described  as  primitive.  The  user  Is 
given  a  choice  as  to  how  messages  can  be  input  and  cutout  to 
and  from  the  screen,  that  is,  the  message  can  be  i,  10,  20, 
30  or  80  characters  long,  and  of  no  other  length.  Counting 
the  number  of  characters  in  one's  input  and  output  text 
significantly  detracts  from  the  art  of  programming. 

Compilation  of  a  user's  ADA  source  code  Is  performed  on 
the  host  VAX  11/780  and  It  proceeds  at  a  respectable  rate, 
the  turn  around  time  was  always  less  than  a  minute.  The 
number  of  compilation  errors  is  displayed  at  the  end  of 
compilation,  however  the  reeson  for  the  errors  Is  not.  To 
evaluate  the  compilation  errors,  INTEL  has  supplied  a  very 
useful  report  facility  which  is  an  image  of  the  original  ADA 
source  code  with  errors  Identified  by  a  diagnostic  message 
and  cede  number.  Unfortunately,  many  of  the  error  code 
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numbers  In  the  INTEL  reference  menuel  just  reoeat  the  same 
diagnostic  error  message,  with  no  further  elaboration. 

There  was  one  very  frustratlno  aspect  of  the  compiler 
output  to  the  screen.  That  Is,  after  compilation  is 
complete,  there  is  no  message  as  to  what  unit  was  just 
compiled.  Since  the  compiler  output  often  scrolls  the 
screen,  this  leaves  it  up  to  the  user  to  remember  what  unit 
has  just  been  compiled,  ADS  programs  consist  of  many  units, 
and  In  more  than  one  Instance  we  found  ourselves  recompiling 
a  unit  that  had  just  been  compiled.  A  very  simple  solution 
to  this  would  be  to  output  the  complied  unit's  name  as  the 
last  line  of  output  along  with  the  error  messages. 

As  with  most  new  compilers,  there  are  some  errors.  The 
more  significant  of  these  are  the  type  that  allowed 
compilation  of  code  representing  features  that  are  not  yet 
implemented.  For  example,  array  assignments  are  not  yet 
operational,  yet  a  source  code  program  containing  them 
compiles  with  no  error  messages.  Execution,  as  expected, 
does  not  occur.  Most  of  the  ADA  restrictions  are  well 
documented  in  the  error  report  file,  however.  It  only  taxes 
one  or  two  which  are  not  Identified  to  causa  significant 
problems  In  debugging  a  program.  At  least  one  type  of  error 
crashes  the  compiler.  That  Is,  a  program  which  needs  a 
large  data  structure  may  never  compile  and  furthermore  the 
user  will  never  be  Informed  as  to  the  reason  for  the 
failure.  This  problem  occurred  with  the  following  program 


unit: 


typ«  item  Is 
record 

key  2  Integer; 
data  :  character; 
end  record; 

type  array.one  Is  arrayC 1 . .2000)  of  Item; 

mm 

begin 


When  array.one  had  2000  elements  the  program  unit  crashed 
the  compiler.  Lowering  the  number  of  elements  to  200 
allowed  satisfactory  compilation. 

a.  LINKER 

The  linking  process  of  a  users  program  Is  tedious.  A 
separate  link  program  needs  to  be  written  for  each  program 
that  is  to  be  linked.  The  time  to  link  a  program  Is 
considerable,  usually  In  the  range  of  two  to  three  minutes, 
Many  default  parameters  occur  In  the  linking  process  which 
can  be  changed  by  directives  in  the  users  link  program,  no 
problems  were  experienced  with  the  default  values,  but 
depending  on  a  default  value  for  proper  program  execution 
can  easily  lead  to  difficult  debugging  errors  In  future 
program  maintenance,  in  our  opinion  all  the  directives 
should  be  required  to  be  explicitly  stated. 

The  linker  has  at  least  one  ambiguous  characteristic. 
After  a  successful  linkage,  a  message  Is  written  to  the 


scrtcn  wnlch  states  "LINKAGE  SUCCESSFUL".  This  message  may 
also  be  accompanied  by  one  or  more  warning  messages.  In 
every  case  that  we  experienced,  if  a  warning  message 
occurred  during  IlnKlng  then  the  program  would  not  execute. 
The  message  "LINKAGE  SUCCESSFUL"  can  be  very  misleading. 

C.  DOWNLOADING 

The  process  of  downloading  programs  from  the  host  VAX 
11/780  system  is  probably  the  biggest  drawbacic  to  the 
432/670  system.  Since  the  IMAX  operating  system  Is  part  of 
the  downloaded  object  files  (EOD).  the  files  regulrlng 
transfer  are  guite  large.  A  typical  small  ADA  program  (less 
than  100  lines  of  source  code)  taxes  nearly  twenty  minutes 
to  download  at  2400  baud.  This  maxes  program  changes  very 
time  consuming.  Even  If  a  9600  baud  line  were  used,  the 
entire  process  of  correcting  source  code,  re-complilng 
affected  modules,  and  then  downloading  them,  requires  a 
significant  amount  of  time.  There  is  a  program  called 
UPDATE  for  merging  a  recompiled  module  of  a  program  with 
the  existing  EOD  file.  The  smaller  re-complled  module  Is 
much  faster  to  download,  about  seven  minutes,  but  the  UPDATE 
program  taxes  about  3  to  4  minutes  to  execute.  The  time 
saved  was  not  considered  significant  to  warrant  use  of  the 
UPDATE  feature.  Especially  since  a  new  llnX  program  would 
have  to  be  written  each  time  it  was  desired  to  recompile  a 
portion  of  a  orogram. 
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0,  DEBUGGING  AND  EXECUTION 

Our  Imprtcslon  of  the  debug  facility  wai  favorable.  It 
allowed  for  access  to  the  program  structure  at  an  assembly 
language  level.  This  did  not  allow  any  type  of  assembly-llKe 
programming  but  did  provide  a  means  to  locate  errors  In  our 
source  code  by  mapping  the  error  location  to  a  source  code 
statement  number.  A  very  useful  utility  Is  the  LOG  program. 
This  allows  everything  that  was  Input  or  output  at  the 
terminal  to  be  logged  for  future  reference.  The  debug 
facility  could  be  made  much  more  user  friendly  by 
implementing  the  ADA  exception  features.  At  present,  the 
laeic  of  exceptions  means  that  run  time  errors  may  not  be 
reported,  and  Indeed  may  cause  the  system  to  crash  with  no 
indication  to  the  user  as  to  the  cause.  An  example  of  this 
occurred  when  one  of  our  orograms  attempted  to  Index  an 
array  outside  the  declared  array  bounds.  No  error  messages 
were  reported,  and  the  system  crashed. 

The  execution  of  a  program  was  difficult  to  Initiate. 
The  following  sequence  of  commands  represents  the  minimum 
time  required  to  execute  a  program  after  the  power  Is  turned 
on  and  the  ISIS-II  operating  system  Is  booted.  The  times  are 
approximate  and  they  depend  on  the  size  of  the  program  that 
is  going  to  oe  executed. 
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eomnand 


tine  required 


RUN  WORK  tFO: 

.5 

min. 

RUN  0EB432 

1 

min. 

INCLUDE  DEB433.TEM 

1 

min. 

INIT 

1 

min. 

DEBUG  "userprogram" 

1 

min. 

START 

Once  the  system  debuqqer  Is  loaded  (once  per  session}  things 
proceed  e  little  faster.  Only  the  last  three  commands  of 
IMIT,  OCBUG#  and  START  are  required  per  program. 

E.  ADA  IMPRESSIONS 

One  of  the  many  interesting  facets  of  working  on  this 
thesis  was  the  exposure  to  the  new  doD  language  ADA. 
Inasmuch  as  our  use  of  ADA  was  limited  to  the  benchmarks  in 
this  thesis,  plus  the  fact  that  we  dealt  with  a  compiler 
which  did  not  fully  Implement  the  language,  our  impressions 
are  limited.  However,  the  features  of  ADA  we  did  exercise 
left  us  with  some  favorable  Impressions. 


The  feature  we 

used  and  liked 

most 

was  the 

ability 

to 

separate  the  specifications 

of 

a  program 

from 

the 

corresponding  body 

of  the  program. 

The 

package 

feature 

of 

ADA  was  used  to  do  this.  A  specification  package  Is  simply 
the  formalizing  In  ADA  of  what  the  interface  of  the  program 
Is  to  be.  l.e..  the  'what'  of  the  program.  The  body  package 
on  the  other  hand  Is  the  formalizing  In  ADA  of  the  manner  In 
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which  one  plans  to  Impiemant  tha  proaram,  l.a.,  the  *how'  of 
the  program.  The  contribution  of  this  separation  Is 
twofoldi 


1.  Given  a  specification  package,  a  programmer  Is 
free  to  Implement  the  program  in  the  manner  he  or 
she  sees  fit.  so  long  as  It  satisfies  the  specif- 
Icatlon.  or  Interface, 

2.  Users  of  a  particular  program  or  programs  need 
only  be  given  the  specification  package  in  ordar 
to  discern  what  the  particular  code  can  do  for 
them.  The  'how'  of  the  code,  or  the  body  package, 
need  net  concern  them. 


Using  this  technique  In  very  large  software  projects 
should  have  a  significant  effect  on  software  development  and 
maintenance.  In  our  small  scale  projects  the  separation  of 
specification  and  body  allowed  for  easy  parallel  development 
of  the  benchmark  programs.  The  acceptance  of  AOS  by  OoD 
computer  personnel  could  be  seen  to  lead  toi 


1.  The  growth  of  software  libraries  with  specifica¬ 
tion  packages  as  the  user  Interface  to  the  li¬ 
brary, 

2.  Greater  productivity  among  programmers.  For  in¬ 
stance.  suppose  a  decision  Is  reached  on  what  a 
particular  piece  of  software  Is  to  do.  This 
"what"  Is  formalized  In  ADA.  and  given  to  the 
programmerCs) .  The  programmer  Is  now  free  to 
bring  all  of  his  or  her  abilities  to  bear  on  suc¬ 
cessfully  Implementing  the  body,  or  the  "how"  of 
the  Piece  of  software. 


Beth  of  these  abilities  are  generally  regarded  to  be  very 
worthwhile,  something  which  up  to  now  has  been  pursued  with 
no  great  degree  of  success.  Supporting  and  thereby 
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faellltatina  this  faatur*  of  paelcaoas  Is  tht  separate 
eoapllatlon  ability  of  A0A«  while  still  enforelnq  strong 
type-eheeiclng  of  Interfaces,  That  Is,  making  sure  that 
parameters  In  the  body  package  are  of  the  exact  same  kind  as 
these  delineated  in  the  specification,  which  may  have  been 
compiled  some  time  before  actual  ceding  was  ever  begun  on 
the  body. 
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VI.  COMCLUSIQNS 


In  Itt  present  state  the  INTEL  Cross  Oevelopnent  system 
(CDS)  Is  very  much  a  development  tool.  Areas  which  we  feel 
could  be  changed  to  improve  the  user  friendliness  of  the 
system  have  oeen  presented  In  the  previous  chapter. 

As  an  execution  vehicle  for  the  ADA  language,  the 
processor  seems  especially  well  suited.  However,  the 
Incompleteness  of  the  compiler  did  not  permit  us  to 
rigorously  exercise  the  432  as  much  as  we  wanted  to.  Though 
the  432  and  ADA  seem  especially  well  matched,  It  Is  not 
reflected  In  program  execution  speed.  An  object-oriented 
architecture,  which  also  Incorporates  system  management 
facilities  In  hardware,  undoubtedly  must  have  some 
drawbaexs.  In  this  version  of  the  432,  this  was 
unfortunately  reflected  in  execution  speed.  As  an  aside, 
when  the  compiler  comes  to  support  floating  point 
operations,  benchmarks  which  exercise  floating  point 
manipulations  should  provide  some  interesting  results.  As 
elaborated  previously,  hardware  support  for  floating  point 
operations  In  the  432  are  outstanding. 

The  lack  of  a  hardware  Interrupt  Is  a  handicap  that 
should  be  capable  of  being  overcome  through  the  use  of  the 
attached  processor.  This  feature  was  not  operational  on  the 
432/670  system  and  therefore  could  not  be  tested. 
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The  tinlnq  perfornence  o£  the  eyiten^  et  first  glance, 
does  not  present  a  very  favorable  Inpresslon.  The  benehnaric 
programs  that  were  compared  with  the  previous  study  by 
HansenCS]  eonflraed  that  the  432  Is  slow  In  It's  execution 
speed.  Execution  speed  Is  but  one  of  many  measures  of  any 
computer  architecture.  It  Is,  however,  a  measure  which 
readily  lends  Itself  to  numerical  analysis  as  opposed  to 
qualitative  features  which  do  not.  This  subjective 
qualitative  category  can  include  such  items  as  the  amount  of 
fault  tolerance  and  protection  available. 

The  multiprocessor  capabilities  of  the  432  provide  a 
case  study  in  some  of  the  Issues  which  must  be  addressed  by 
any  system  using  multlprocesslno.  Moreover,  the  system  in 
general  oermits  one  to  analyze  the  more  basic  concepts  of  an 
ooeratlnq  system.  Processes,  Inter-oroeess  communication, 
ready,  running,  and  blocked  states  are  all  generic  terms  to 
the  architecture.  Any  study  of  the  processor's  architecture 
cannot  help  but  to  provide  an  excellent  insight  into  these 
concepts. 

Finally,  the  architecture  has  been  designed  to  be 
programmed  in  a  high  level  language  only.  As  the  compiler 
Inefficiencies  are  removed  and  the  cost  of  procedure 
Invocation  Is  lowered  the  432  should  show  a  marked 
Improvement  In  It's  overall  performance. 
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APPENDIX  A 


HARDWARE  DESCRIPTION 


This  thssls  ustd  a  modified  INTEL  MDS  SYSTEM  800 
interfaced  with  the  lAPX-432  execution  vehicle.  This  setup 
required  a  special  circuit  board  to  allow  communication 
between  the  mos  800  system  and  the  432/670.  The  chassis 
nape,  slot  number,  and  board  number  of  the  system  components 
used  in  this  evaluation  follow. 


Card  eaqe  number  to  circuit  board  identification 
MDS«800  board  description: 


1/ 

2. 

3. 

4. 

5.  RPB<-86 

6. 

7, 

8. 

9. 

10. 

11. 

12. 

13. 

14. 

15. 

16. 

17.  432  IP  INTEL  432/670  172080-006-rev  H 
S/N-xp-000198 

18. 

432/670  board  description: 


1. 

2. 

3. 

4. 
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5.  MEMORY  INTEL  112340*004  REV  C  112354-001  REV  C 
S/N  000279 

4.  MEMORY  INTEL  112340-004  REV  C  112354-001  REV  C 
S/N  000262 

7.  MEMORY  CONTROLLER  INTEL  172075-005  REV  E 
S/N  -xp-000033 

8.  GOP  INTEL  432/601  005  REV  F  S/N-xp-000187 

9.  GOP  INTEL  432/601  MF-006  REV  H  S/N-xp-000104 

10.  GOP  INTEL  11/16/82  432/601  MP-005  REV  F 

S/N-xp-000095  MO-17-0003 

11. 

12.IP.L2NK  INTEL  432/603  172028-004  REV  E 
5/N-XP-000-227 
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APPENDIX  B 


OPERATING  SYSTEM  MODIFICATIONS 


Tht  iMAX-432  oper«tin9  system  supplied  with  the  432/670 
wes  net  eempetlble  with  the  herdwere  cent Iquretlon. 
Specifically,  Interface  processors  are  not  yet  supported, 
even  thouoh  tne  1max*432  operating  system  Is  configured  for 
them.  This  necessitated  a  change  to  the  ADA  oactcage  body 
that  describes  the  system  processor  configuration.  The  name 
of  this  pacicage  Is  PSORS.mbs.  The  code  referring  to  the 
number  of  processors  and  Interface  processors  In  the  pacicage 
body  PSORS.MBS  must  be  changed  to  reflect  the  current 
physical  state  of  the  432/670  system.  For  a  three  GDP  board 
configuration  with  no  IPL  boards,  the  PSORS.MBS  would 
Include  the  following  descrlptlont 


Define  GDP  boards  present 

package  psorl  Is  new  GOP«Def (psor.num  3>  i); 

package  p8or2  Is  new  GDP«Def (psor.num  s>  2}; 

package  psor3  Is  new  GDP.Def (psor.num  s>  3); 

processorl:  processor  retypes  psorl. psor; 
proeessor2:  processor  retypes  psor2.psor; 
processors!  processor  retypes  psorS.psor^ 

-•  Define  empty  slots 
processors!  constant  processor  !■  null! 
proeessor4!  constant  processor  :s  null; 
processors!  constant  processor  !■  null! 


A  complete  discussion  as  to  how  these  changes  can  be 
Incorporated  In  the  PSORS.MBS  package  can  be  found  In 
Reference  7. 
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APPENDIX  C 


ADA  SOURCE  CODE 

All  Of  th«  bonehfliark  proorams  that  ware  coded  in  ADA 
follow.  Most  proorams  are  composed  of  three  parts.  That  ls« 
a  packaqe  specification.  oacKage  body,  and  a  driver  or  main 
routine.  The  respective  oarts  are  labeled  accordlnolv.  The 
programs  obtained  from  U.C.  Berkeley  are  composed  of  just  a 
single  main  routine.  For  easy  cross  reference  the  program 
name  and  the  corresponding  benchmark  program  are  listed 
below. 

e 

program  namel  program  description 

. . . . . 


CHARSl 

a 

a 

Character  search  with  procedure 
overhead. 

CHARS2 

: 

Character  search  without  procedure 
overhead. 

OUICKI 

Quicksort  iterative 

0UICK2 

a 

a 

Quicksort  recursive 

HASHl 

1 

Hash  function 

DCOMl 

a 

a 

Digital  Communication  with  procedure 
overhead. 

DC0M2 

a 

a 

Digital  Communications  without  procedure 
overhead. 

MEMi 

1 

Recursive  memory  test 

MEM2 

a 

a 

Iterative  memory  test 

SEARCH 

s 

U,C,  Berkeley  character  search 

SIEVE 

: 

U,C,  Berkeley  prime  number  generator 

ACKER 

! 

U,C,  Berkeley  Ackerman's  function 
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In  addition  to  tha  programs  abova  ,  two  otnar  programs  ware 
coded  In  ADA  but  ware  net  executed  due  to  compiler 
limitations.  The  Punge-Kutta  integration  was  coded  and  the 
source  cede  appears  under  the  program  name  RUNGE.  Some  of 
the  programs  were  extensively  tested  under  an  ADA-ED 
Interpreter,  The  linked  list  insertion  program  was  written 
and  tested  In  ADA-EO  and  the  source  code  for  It  is  under  the 
program  name  LINK.  The  reader  is  warned  that  these  two 
programs,  RUNGE  and  LINK  have  NOT  been  tested  under  ada-432 
and  some  modifications  may  be  necessary  to  get  them  to 


execute 


CHARSl  packaqe  specification 


TMs  is  the  ADA  specification  Package  for  the 
--  CFA  character  search  benchmark. 

—  CHARSl 


package  SChAR  is 

subtype  subint  is  integer  ranae  t..256; 
type  tstarrav  is  array ( 1 . .256)  of  character; 
ar ray  I » ar ray2  :  t*tarray; 


Procedure 

ROFIL; 

procedure 

SEARCH(srchlen,ara1en 

;  IN 

subint; 

array  1 . array2 

:  IN 

txtarray; 

1  oc 

;  OUT 

subi nt  )  ; 

end  SCHAR; 


-«  CHARSt  package  body 


pragma  en v i ronmen t ( " ACS t TEXT  10 .MLE" , " I  NT  1 0 , MSE " » 

-SCHAR. MSE") ; 

with  text«-i  0*  i  nt  i  o;  use  text^’io*  int  io^asc  i  i  ;  , 
package  body  SCHAR  is 
procedure  ROFIL  is 
1  i  ne«-of  ri  nout  :  strinqSO; 
char  :  character; 
i » i  ;  i nteger ; 

begi  n 
sk  i  o*-1  i  neJ 
new*-l  i  ne( ) » 

out*-1i  ne^30  (  "Ent  er  Srch-strnqr  $  ends . ") 

i ;  s  1  ; 

while  i  <  256  1 oop 
1  i  ne*"© f  «•  i  nput  Get*-!  i  ne^50  ( ) ; 

exit  when  1  i  ne«'0  f  i  nput  (  I )  = 
for  j  in  1..0O  1 oop 
exit  when  1  i  ne^of  i  nput  ( j )  *  '  ’  and 

1  i  ne*-of  i  nput  (  i  ♦  1 )  =  *  '; 
arrayl(i)  ;=  1  i  neeof  •■i  nput  ( j ) ; 
i  :=  I  +  1 ; 
end  loop; 
end  loop; 


fill  array  2 


new«*l  i  ne ( ) ; 

out^-n ne«-30 ( "Enter  Srch-arq»  S  ends . 

i  :=  I ; 

while  i  <  256  1 ooo 
H ne^-of *^1  nout  Get^l  i ne^-SO ( ) » 

exit  when  1  i  ne^'Of  ♦i  nout  ( 1)  ~  'S'» 
for  i  in  I, .80  Joop 
exit  when  1  i  ne^'O  f  ♦■i  nout  ( j )  =  *  '  and 

H  ne<*of  ♦•i  nout  ( i  ♦  t )  =  ’ 
arrav2(i)  1  i  ne»-o  f  ^i  nout  ( I  ) » 
i  :  =  i  + 1 ; 
end  looo; 
end  looo; 

--  check  the  array's  contents 

new«-1  i  ne  ( ) » 
for  i  in  1  . .  80  looo 
out (array  1 ( i  )  )  * 
end  looo; 
new4>1  i  ne( ) ; 
for  i  in  1  .  ,80  looo 
Dut(array2(i)); 
end  looo; 

out  H  ne^  1  0  (  "  end  POFIL  "); 
end  RDFIL; 

orocedure  SEARCH ( s rc h I en , aral en  :  IN  inteoer; 

arrayl»array2  :  PI  txtarrayl 

1 oc  ;  OUT  inteoer)  is 

i » i  :  t  nteqer ; 
beoi  n 
i  :=  i; 
i  :=  i; 
loc  :=  -1 ' 

while  i  <~  srchlen  looo 
if  arrayl(i)  =  array2(j)  then 
if  i ♦ 1  <-  arqlen  then 
i  :=  i +1 ; 

)  :  =  j  ♦  1 ; 

el  se 

loc  i“i; 
exit; 
end  if; 
el  se 

i  :=  i tl ; 
j  ;s  i; 
end  i f ; 
end  looo; 
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end  search; 
end  SCHAR; 


CHARSl  driver  routine 


praqma  envi ronment ("ACS:TEXTI0.MLE"» "INTIO.MSE" » "SCHAR.MSE' 

-MAIN.MSE*); 

with  tex  t  *-i  Of  i  nt  i  o » schar ;  use  te*t*^io»  i  nt  i  o»  schar »  asc  i  i  » 


--  RDFIL  and  SEARCH  contained  in  the_same  oackage 
•”  Timinq  also  includes  time  for  orocedure 

invocation. 

—  l«  Oct.  IR82 

oackaqe  body  USERePROCESSel  is 
orocedure  HAIN  is 

i  » 1  oc  »  srch«- 1  enqt  h  »  srcheara»  t  i  merel  OOP  :  inteoer; 
forever  :  boolean  :=true; 
answer  :  character; 

begin 

while  forever  1 ooo 


--  initialize  the  arrays 

m  m 

for  i  in  1 , ,256  1 ooo 
array  I  ( i  )  *  '  » 

array2( i  )  t*  '  '  » 
end  loop; 


••  get  the  search  arguments 
newel i ne(  )  ; 

oute30 ( "Charac ter  search  O^Ouits . ")» 

get ( answer ) ; 

exit  when  answer  =*Q'; 

RDFIL; 
newel i ne  ( )  ; 

oute30 ( "Lenot h  of  string  to  search?..."); 

qet(srchelength); 

newel i ne( ) ; 

oute30 ( "Lenqt h  of  string  to  search  for"); 
get ( srchearq) ; 
newel i ne{ ) ; 

oute30 ( "Number  of  looos  to  time......,"); 


P? 


get ( t iffler^looo) f 
new^  H  ne ( ) » 

Dut^20("  Start  of  Search ? 
out(BEL); 

for  i  in  1..  timer^looo  1 ooo 

SE ARCH ( arch*- 1  enqth»arch*'arg»  array  1  »arrav2f  1  oc  ) 
end  tooD» 
outCBEL); 
new^l i ne( ) » 

Dut^20(*end  the  search..,...")? 
new*-1  i  ne  (  )  * 

Dut«-1 0  ( "Locat  i  on=  "); 
out ( 1 oc  )  ? 
skio*"!  i  ne» 
end  iooo; 

end  main; 

end  USER^'PROCESS*! ; 
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CHARS2  oackaqe  specification 


oackaqe  SCHAR  is 

tvoe  txtarrav  is  acrav ( 1 • *256)  of 
arravl #arrav2  :  txtarrav; 
orocedure  RDFIL# 

procedure  SEARCH(srch 1 en» arql en  : 

array  I , ar rav2  S 
i  oc  ; 


end  SCHAR; 


character; 


IN  integer; 

IN  txtarray; 
OUT  integer); 


--  CHAR32  oackage  body 


--  Timing  oromots  in  the  body  of  the  search  procedure 

pragma  envi ronment ( " ACS : TEXTIO .mlE “ , " INT 10 . MSE " , 

"SCHAR. MSE*); 

with  t  ex  t  ♦•i  0/ i  nt  i  o;  use  t  ex  t  ♦•i  o»  i  nt  i  o »  asc  i  i  ; 
package  body  SCHAR  is 
orocedure  RDFIL  is 
1  i  ne«'Of  ♦•i  nout  :  strinqSO; 
char  :  character; 
i » j  :  i nt eoer ; 
begt  n 

sk  i  o*-1  i  ne ; 
new*-!  i  ne  ( ) ; 

out*- H  ne*'30  ( "Ent  er  Srch»strna,  S  ends . "); 

i  :si ; 
jtsi; 

while  i  <  256  I oop 
I  i  ne^of  *-1  nout  :=  Get«-1  i  ne«-0O (  )  ; 

exit  when  1  i  ne*-of*-i  nput  ( 1 )  ~  'S’; 
for  j  in  1  ,  .00  1  OOP 
exit  when  1 i ne^of ^i nput ( j )  =  '  '  and 
1  i  ne^'Of  «■  i  nout  (  i  + 1  )  ~  '  '} 
arrayHi)  !-  1  i  ne^of  ♦■i  nput  ( i )  ; 
i  ;=  i tl ; 
end  loop; 
end  loop; 

--  fill  array  2 

new*-l  ine( ) ; 

out^l  i nee30 ( "Ent er  Srch-arg,  S  ends . "); 

i  :s  i; 

while  i  <  256  loop 


1  {  ne^of^i nput  «“  Getfr  1  ine^’SOC ) ; 

exit  when  H  ne^'of^-i  nout  ( 1 )  =  '$'? 
for  }  in  I . .80  1 ooo 
exit  when  H  ne*-of  ♦•i  nput  ( j  )  =  *  '  and 

1  i  ne^of  ♦■i  nput  ( }  ♦  I )  =  *  '? 
array2(i)  •-  1 i ne^of^i nput ( i ) ? 
i  :  =  i  ♦  1 ; 
end  loop# 
end  loop# 

--  check  the  array's  contents 
end  ROFIL; 


procedure  SEARCH ( srch 1 en » arql en  :  IN  integer; 

array  I # arrav2  !  IN  txtarray# 

loc  :  OUT  integer)  is 

i  » i »  k»  t  i tner«-1  ooo  ;  integer# 
begi  n 

new«- 1  i  ne  ( )  » 

out^30 ( "Number  of  1  oops  to  t i me .»....»")  # 
get ( t i me r^) ooo) » 
new^ 1 i ne ( ) # 

out*-20("Start  of  search . ")» 

out ( BEL )  # 

for  k  in  1 . , t i mer^l OOP  loop 
i  :=  i; 
j  :=  i; 
loc  :=  -I # 

while  i  <=  srchlen  loop 
if  arrayl(i)  -  arrav2(j)  then 
if  j  + 1  <=  argl en  then 
i  :=  i  +  l ; 
j  := 
el  se 

loc  : *  i - j  # 
exit# 
end  i f  # 
el  se 

i  :=  i ft  # 
j  ;=  1#* 
end  i f » 
end  loop# 
end  loop# 
out (BEL); 

out*-20("end  the  search . ")» 

new*>l  i  ne  ( )  # 


end  search; 
end  SCHAR; 

--  CHARS?  driver  routine 


pragma  envi ronment ("ACStTEXTIO.MLE'r "IWTrO.MSE’r "SChAR.MSE" 

-MAIN.MSE"); 

with  text*'i  o#  i  nt  i  o/ schar ;  use  text  «-i  o  >  i  nt  i  o  *  schar  ^  asc  i  i  ; 

••  ROFIL  and  SEARCH  contained  in  the  same  package 

“•  Timing  is  for  the  SEARCH  only.  Prompts  are  from 

•“  the  SEARCH  orocedure 

la  Oct.  1R82 

M  am 

package  body  USER«-PR0CESS«-1  is 
procedure  MAIN  is 

i  » 1  oc  »  srch*"!  enqt  h  »  srch+'arq  :  integer; 
forever  :  boolean  tstrue# 
answer  ;  character; 

begi  n 


DuteSO ( "chars?  with  a  qdo  conf i ourat . . " ) » 
new^l i ne ( ) ; 


while  forever  1 ooo 

•  me 

i^itia1i^e  the  arrays 

for  i  in  l..?56  loop 
array  I ( i )  ;=  '  ' ; 

array?( i )  :=  '  '  ; 
end  loop; 


•-  get  the  search  arguments 
new*'l  i  ne( ) ; 

oute30 ( "Character  search  QsQuits . "); 

get (answer) ; 

exit  when  answer  s'Q'; 

rofil; 

new^MneO; 

Dute30( "Length  of  string  to  search?,,."); 
get (srchelength) ; 
new*^l  i  ne  ( ) ; 


put*«30("Lenqth  of  stP<nq  to  search  for"); 

qet  (srch«-a*rq)  ; 

new*'Vine()# 

SE ARCH ( arc h4*lenqth,archearq»ar pay  1 » arrays » loc 
Dut^lO("Locat ion=  ")» 
put ( 1 oc) f 
sktP**l  ine» 
end  loop# 
end  main; 

end  USER«-PRQCESS«-l ; 
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1. 


>~0UICK1  oactcage  soec  i  f  i  cat  i  on 

mm 
m  m 

““  QUICKSORT  oackage  specification  (Iterative) 


packaqe  QUICKSORT  is 
type  item  is 
record 

Wev  :  integer; 
data  :  character; 
end  record; 

tyoe  inarray  is  array(1..20)  of  item; 
procedure  SORTCarg  :  IN  OUT  inarray); 
end  quicksort; 


--  gUICKl  package  body 

--  QUICKSORT  package  body  (Iterative) 

m  m 

pragma  envi  ronment  ("ACS:TEXTIO.^<LE"#"IMTIO.MSE"/ 

"QUICK. MSe-); 

with  text^-io#  intio/Quicksort; 
use  text^i o» i nt i o»aui cksort ; 
package  body  QUICKSORT  is 
Procedure  SORT(arg  :  IN  OUT  inarray)  is 
m  :  constant  :=  20; 
i r  j / ) / r  :  i nt  eger ; 
mid*-ot»temo  ;  item; 
type  stack^frame  is 
record 

Ifr  :  integer; 
end  record; 

stack  :  array(l*«m)  of  stack*-? name; 
s  ;  integer; 

mm 

Begi  n 
I  :  =  1  ; 
r  !=  20; 
s  ;=  i; 

stack(l).)  :=  1; 
stack! 1 ) .r  20; 

1  OOP 

1  stack(s)  •  I ; 
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p  8tackCs).p» 
s  :=  s-l» 

1  OOP 
i  :s  1 ; 
i  1=  ri 

tii<d«*ot  !=  arg ( ( 1  ♦  P ) /2) ; 

1  OOP 

while  apgfn.kev  <  mtd^ot.Wev  loop 
i  :=  i >1 ; 
end  loop; 

while  mid^-ot.kev  <  ^paCjl.lcev  loop 
i  :s  i-i; 
end  loop? 
if  i  <=  j  then 
tewp  :=  apgCi); 
apg( i )  J =  apg( j 1  * 
apq(j)  !“  temp* 
i  :s  i t 1 ; 
j  :=  i-1? 
end  i f  * 

exit  when  i  >  j  * 
end  loop* 
if  i  <  p  then 
s  :3  stl* 
stack(s)«l  :*  i* 
stack(s).p  p» 
end  i f  * 
p  :s  /; 

exit  when  1  >-  p* 
end  loop? 
exit  when  s  =  0* 
end  loop* 
end  sort; 
end  QUICKSORT; 


--  OUICKl  dpivep  poutine 

--  QUICKSORT  oackage  body  fop  Opivep  (Itepative) 

ppagma  envi ponment ("ACS: TEXTIO.mlE"* "QUICK. MSE"* 

-INTIO.MSE"*"MAIN.MSE") ; 
with  quick80Pt*text*-io»  intio* 

U8e  quick80Pt*texteio*intio*a8Ci i f 
package  body  USERePROCESSel  is 
ppocedupe  WAIN  is 
apg* tempeappsy  :  inaPPay* 
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i f loop^val f i  :  integarf 
data  :  boolean  :s  true* 

Begin 

for  i  in  1«*20  1 ooo 
arg(i).key  :=  0; 
arg({).data  's'; 
end  loop* 

new**!  i  ne(  ) » 

out**!  ine**20("QUlCKSORT  BENCHMARK  ) 
out*'!  i  ne*20  (  "Iterative  Version,,.") 
out*20( "Enter  key*  followed  "); 
out*20 ( " i wmedi at e! y  by  data*")* 
out*!  ine*20("  0  terti i nates ) 
new*! i ne () » 
i  :s  1 ; 

while  data  loop 
get (arg( i )  .key) * 
exit  when  arg({),key  =  0* 
skip*! i ne* 
get  Carg(i ) .data) * 
i  :*  i tl ; 
skip*) i ne* 
end  loop; 
new*! i ne ( ) * 

out* 1 i ne*l 0 ( "Your  Input")* 
for  i  in  I, .20  ! ooo 
out (arg( i ) .key) * 
out (arg( i ) .data) * 
new*! i ne ( ) * 
end  loop* 

R 

Loop 

out*30 ( "Number  of  looos  to  time..,, 
get ( ! ooo*v8 1 ) ! 

exit  when  (!ooo*val)  *  0? 
new* ! i ne ( ) * 
for  i  in  1..20  ! ooo 
temo*array ( i ) . key  :*  arg(i),kev; 
tefflO*8rray C i ) .dat a  :•  sra(i).data* 
end  loop* 

out*20("Start  of  Quicksort,."); 
out (be! )  * 

for  i  in  1 . . ( ! ooo*va!  )  looo 
for  j  in  1..20  looo 
argfD.key  :*  temo*array  f  i  )  .  kev; 
arg(i).data  temo*8rr8y( j ) .data 


g 


end  toopr 
30RT(arg) ; 
end  loop; 
out (bel ) r 
new^HneOJ 

put^l ine^20(*End  the  Quicksort. 
out«‘Hne^lO(”The  Output”)* 
for  i  in  1..20  1 ooo 
out (arq( i ) .key) t 
out (arq( i ) .data) t 
new^l i ne ( ) * 
end  loop* 
end  Loop* 
end  main; 

end  USER«-PR0CESS«-1 ; 


QUICK? 


Dackaqe  soac i f i cat t on 

--  QUICKSORT  oackaqe  specification  (Recursive) 

package  QUICKSORT  is 

tvoe  item  is 
record 

key  :  integer# 
data  :  character# 
end  record# 

tvoe  inarray  is  arr8y(1..20)  of  item; 
subtype  subint  is  integer  range  1..20; 

orocedure  SORT () eft # ri ght  :  in  subint# 

arg  :  in  out  inarray)# 


end  quicksort; 


--  QUICK?  package  body 

--  QUICKSORT  package  body  (Recursive) 

pragma  envi ronment ( " 4CS : TEXTIO.MLE" # " IMT 10. mSE" # 

"QUICK. MSE") ; 

with  t ext^i o# i nt i 0# qui c ksort »  use  textri o# i nt i o#qui cksort 

package  body  QUICKSORT  is 

procedure  SORT ( 1  eft # right  :  in  subint; 

arg  ;  in  out  inarray)  is 


i#j  :  subint; 
mid^ct»temo  :  item; 

Begi  n 
i  :=  lef t ; 
j  : s  right# 

mid^pt  ;=  arg ( ( 1 ef t ♦ r i gh t ) /2) ; 

1  OOP 

while  arg(i).i«ev  <  mid^ot.kev  i  oop 
i  :  =  i  ♦  1 ; 
end  loop# 

while  mid*-ot.kev  <  arg(i).kev  I'.oo 
I  !=  i-1#- 
end  loop# 
i f  i  <*  j  then 
temp  arq( i ) ; 
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arg(n  :*  arg(j); 
aro(j)  :*  temp; 
i  :»  i ♦! ; 
i 

end  if; 

exit  when  i  >  j; 
end  loop; 
if  left  <  j  then 
SORTdeft,  i.apq); 
end  i  f  f 

i f  i  <  right  then 
SORT(i»riqht»arq); 
end  if; 
end  SORT; 
end  QUICKSORT; 


--QUICK2  driver  routine 

--  QUICKSORT  oackac*  body  for  Driver  (Recursive) 

m  m 

pragma  envi  ronmen t  ("ACS!TEXTIO.MLE"/'*OUICK.msE"» 

"Intio.mse","main.'^se“); 

with  qui  cKsort » t  ext*-!  Of  i  nt  i  o; 
use  quicksort»textmiOfintio»ascii; 
package  body  USER*-PROCESSel  is 
procedure  MAIN  is 
arg» templar  ray  :  inarray; 

1  ef  t«*i  ndex  f  r  i  qht^'i  ndex  ;  subint? 
ifloop^valfj  ;  integer; 
data  :  boolean  true* 

m  m 

Begin 

for  i  in  I. ,20  1 ooo 
arg( { ) , key  : s  0 ; 
arg( i ) .dat  a  : =  ' a  ' ; 
end  loop; 

«•<» 

newel i ne ( ) ; 

outel inee20("gUlCKSORT  BENCHMARK  "); 
oute20("Enter  key»  followed  ")* 
oute20("immedi atel y  by  data»"); 
oute 1 i nee20 ( "  0  t erm i nat es . , . , * , * " ) » 
newe  lined; 
i  ;=  i; 

while  data  1 ooP 


get (arg( i ) .key) » 
exit  when  arg(i).kev  =  Of 
skto^-Hne; 
get (arg( i ) .data) ! 
i  :=  1 tl ; 
skiD^'l  i  ne» 
end  Iood; 
newe I i na ( ) » 

outfr  1  i  ne*-l  0  (  "YouP  Inout")? 
for  i  in  1 .  .20  1 ooo 
out (arg( i ) .key) * 
out (arg( i ) .data) / 
new*-)  tneO » 
end  Iood; 

Looo 

out*"30("i»  of  loooa  to  time?..0  exits 
get ( I ooo^va 1 ) f 
exit  when  (1ooo*-va1)  -  Of 
new^ 1 i ne ( ) ; 
for  i  in  1..20  looo 
temo^ar Pay ( i ) • key  apg(i).key; 
temp^appay f i ) .data  apg(i).data; 
end  looo; 

out«-20  ( "St  aPt  of  Qu i  c ksopt . . "  ) ; 
out  fbe) ) ; 

for  i  in  1 . . ( 1 ooo^va 1 )  looo 
f OP  i  in  1 . .20  1 ooo 
apg(j).key  !=  temox*aPPay(  j )  .kev; 
apg(j).data  t  emo^-appay  (  J ) .  dat  a ; 
end  loop; 

1  ef  t*"!  ndex  :=  1  ; 
pight^-index  20; 

S0RT(1eft«-index»  pi  ght^-i  ndex  r  apq) ; 
end  looo; 
out (bel ) ; 
new*’l  i  ne( ) ; 

out*- 1  i  ne*‘20  ( "End  the  Oui  cksopt .  .  .  "  ) ; 
out*-1  i  ne*"!  0  ( "The  Ou'cout"); 
f OP  i  in  1 . .20  I ooo 
out ( apg( i ) . key ) ; 
put (apg( i ) .data) ; 
new«-1  i  ne  (  ) ; 
end  looo; 
new^l ineC) f 
end  Loop; 
end  main; 

end  USER«‘PR0CESS«-1 ; 


**  HASHl  oackaQe  soec i f i cat  1  on 
package  HASH  is 

m  * 

sire  ;  integer  :*  10; 

table  :  arpav(0,.9)  of  integer; 

m  • 

function  HASHES(key  s  IN  integer)  return  integer; 
end  HASH; 


--  HASHl  oackage  body 

pragma  envi ronmen t ( " ACS : TEXTIO.MLE" , " INT lO.HSE" , "HASH. HSE" ) 

with  text*-io*intio; 

use  tex t^i o/ i ot i o# asc i i ; 

package  body  HASH  is 

function  HASHES(key  :  IN  inteoer)  return  integer  is 
check»i  :  integer; 

Begin 

compute  the  first  place  to  look 
check  :s  key  mod  sire; 
for  i  in  1.. sire/2  loop 
if  table(check)  =  key  or  table(check)  s  0 
then 

return  check; 
else 

check  ;=  (check+i)  mod  sire; 
end  i f ; 
end  loop; 
return  0; 

end  hashes; 

end  HASH; 


HASHl 


driver  routine 


hash  table  search  benchmark 


hashl.eod  on  disk 

••  timing  includes  procedure  invocation  overhead 

pragma  envi ronment (“ ACS ; TEXT IO.mlE" INT lO.MSE" » "HASH. HSE" , 

-HAIN.MSE"); 

with  text*”!  Of  i  nt  i  Of  hash; 
use  text ►i Of i nt i o f HASH, asc i i ; 
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UNCLASSIFIED 


THE  INTEL  432/670  AND  ADA  PERFORMANCE  BENCHMARKSIU) 
NAVAL  POSTGRADUATE  SCHOOL  MONTEREY  CA 
D  d  APPLEGATE  ET  AL.  DEC  82 


package  body  usar«-orocass«*l  fa 


procadurp  main  is 

timar«>1ooP»position»kay* }  :  integer; 
answer  :  character; 

forever  :  boolean  true; 


begin 

new*-l  i  ne  (  )  ; 

Dut«-20  ( "HASHl  benchmark....,"); 


fill  the  hash  table  with  CFA  sample  entries 

table(O)  :s  0; 
tabled)  :3  183; 
table(2)  li; 

tat>le(3)  1035; 

table(a)  ;2  1035; 
table(5)  ;s  183; 
table(6)  ::  86; 
table(7)  :*  0; 
table(8)  ;s  183; 
table(9)  :s  183; 

while  forever  looo 


newel i ne( ) ; 

oute20 ( "Cont i nue?  Q:  quits."); 

get (answer) ; 

e«it  when  answer  s  'O'; 


newel i ne(  )  ; 

oute20("enter  an  integer  key"); 
get ( key ) ! 

newel ine( ) ; 

oute30 ( "number  of  looos  to  time . ")» 

get ( t i merel oop) ; 

newel i neC } ; 

pute20("start  hash  lookuo..."); 
put (bel ) ; 

for  i  in  1 .. t i mere! OOP  looo 
position  :s  HASHES(key); 
end  loop; 
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out (bel ) } 
n«M^1 i ne( ) J 

put^20("«nd  of  hash  lookuD.. 
new^l i na( ) j 

'Dut^20("hash  oosition  s  .... 
out (posi t ion)  ; 
ski  o«’H  na; 

and  loop) 

new*-!  i  na  C ) » 

out«'30("end  of  HASH  tabla  lookgo. 
end  wain? 

nd  usereppocesswl ; 
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OCOMl  oackage  aoaci f ieatlon 
•"  Ofgital  Communication  Proeassing  Program 
—  19  Oct  82 

pragma  anv i ronmant ( " ACS : TEXT lO.MLE" ) ! 
with  taxt^'io  ;  use  text^io; 

Package  0IG«*C0M  is 
cl  :  constant  :=  lO; 
c2  :  constant  :=  10; 
subtyoe  dest*-tvoe  is  integer  ranoe 
subtyoe  con«-id^tyoe  is  integer  ranqe  l..c2; 
type  message; 

type  messaqeeotr  is  access  message; 
type  message  is 
record 

destination  :  destetyoe? 
connection  :  conei d*-tyoe; 
si2e  t  integer; 

data  :  string30; 

end  record; 

subtyoe  bufeindex  is  integer  range  l..c2; 
type  buf^-^bl  is  apray(l..c2)  of  taufeindex; 
t^yoe  bufetbit-otr  is  access  bufetbl  ; 
d'est  i  nat  i  onetbl  :  array(l..cl)  of  bufetb  Teot  r ; 
bufferearray  s  arravfl..c2)  of  stringSO; 


procedure  forward(mso:  IN  message^-Pt  r )  * 


end  DIGICOM; 


•«  DCOMl  package  body 

ee* 

pragma  envi ronment ("ACSrTEXTIO.MLE", "OCOM.MSE", "INTIO.msE") 
with  texteio# int io  ;  use  t ex tei o» i nt i or asc i i ; 

package  body  OIGeCOM  is 

procedure  forward(msg  :  IN  message^'Ot  r )  is 
i * i  !  i nteger; 
buffereindex  :  bufeindex; 
line  :  buf^tbleptr; 
bufeerray  :  bufetbl; 
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beqi  n 

1{n«  :s  destlnatfon^tbt (msq.destinaCion); 

buf«‘8Pray  Hne^all* 

i:ai; 

while  buf  ♦■array  ( i )  /“  msq.connect  i  on  looo 
iis  ifi; 
end  1 ooo» 

buffer^index  :*  bu^^arrav( i ) ? 
bu f fer^ar ray (bu f fer^t ndex )  l*  msq.dafa; 
end  forward; 
end  digicom; 


--  OCOMl  driver  routine 
-•  diqital  communication  benchmark 
—  0C0M12.E00  on  disk 

--  timing  includes  orocedure  invocation  overhead 

mm 

•*  26  Oct  1982 

pragma  env i ronment (" ACS : TEXTIO.mlE" »" IhT lO.MSE" , "DCOM ,msE " , 

-MAIM.MSE"); 

with  text**!  o»  i  nt  i  o»  OIGeCOM; 
use  t extri o# i nt i o > DIGICOM r esc i i ; 


oaekage  body  user^orocesael  is 
procedure  main  is 
i»j  ;  integer; 
timerelopp  :  integer; 
k  ;  buf^index; 
buf^-tabl  e^ot  r  :  buf^tbleotr; 
msgeout  :  messaqeeotr; 
forever  ;  boolean  :=  true; 
answer  :  character; 

begin 

oute30( "chars*.  9  gdo  configuration..."); 

mm 

newel ine( ) ; 

oute30 ( " t imi nq  includes  oroc  ovhd . "); 

-*  initialize  the  destination  table 
newel i ne ( )  ; 
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out«>30(”{n{  t  destination  tabi  a.  7 

for.  1  in  1  ..el  looe 
dast  1  nat  i  on^tbl  ( i )  :*  naw  buf^-tbl  J 
and  looof 

•“  initiaiica  all  bufrtbl’s 
naM^linaO; 

DUt»30("  ini  t  buf^tbl's... . .....*)! 

for  i  in  t..cl  tooo 

buf^-tabla^otr  *=  dost  inat  ion*>tbl  ( i  ) ; 
for  jin  l..c2  1 ooo 

buf^-tablarotrC  i )  :=  J; 
and  looo* 
and  looD* 


-•  initializa  buffer 


naw«>1  inaO  ; 

out^20("init  the  buffer . ")? 

for  k  in  l..c2  1 ooD 

buf far^array (k)  :s  " . . 

and  loool 


nawa I i na ( ) 7 
while  forever  looo 

outalO("cont inua?  ")» 
oat (answer ) ; 
e«iit  when  answer  s’N*j 
esqaout  :s  new  nessaaa; 
esgaout.siza  0; 
newel i na( ) » 

oute20("start  digit  comm...,"); 
newel i ne ( ) 7 

oute30 ( "enter  destination*  conn* data. 1 
gat ( esgeout .destination); 
skioel ine; 

get (msgeout .connect  ion); 
skioel ine; 

nsgeout.data  isgatel inee30( ) ; 

newel inaC ) ; 

oute30 ( "number  of  looos  to  time......."); 

gat(timareloop}; 
outel 0( "sandi ng. . . " ) ; 
out (bal ) ; 

for  i  in  1 . . t i marel ooo  looo 
forward(msgeout ) ; 
and  looo; 
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out (bel) ; 

DUt*>20  ( "  .  ,  .done  sendinq . "); 

neu*"l  i  ne  ( )  ? 

out*-20 ( "buf f er  flush  is . "); 

for  |{  in  l..c2  looo 
out (k) ; 


Put  ♦•I  i  ne«'30  (buffer«'arrav(l()); 
new*"!  i  ne  ( ) » 
end  looo* 
ski  0^1 i ne* 
end  looo; 
new*- 1  i  ne  ( )  * 

out^20("enrt  of  decom 1 ; 
end  main* 

end  user^-orocess*"!  * 
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--  DC0M2  oackage  soec i f i cat i on 

-*  Digital  Communication  Processing  Program 

—  19  Oct  82 

pragma  env i ronment ("ACStTEXTIO.MLE"); 
with  text^io  t  use  text*"'©? 

Package  OIGeCOM  is 
cl  :  constant  10; 

c2  S  constant  :*  10; 

subtype  dest4-tvoe  is  integer  range  l,.cl; 
subtype  con4- i  g«-t  yoe  is  integer  range  l,.c2; 
type  message; 

type  messaae*-ptr  is  access  message; 
type  message  is 
record 

destination  :  dest«-tvoe; 
connection  ;  con«-i  d«*t  ype; 
siie  ;  integer; 

data  :  string30; 

end  record; 

subtype  buf*-index  is  integer  ranae  l..c2; 
type  buf«-tbl  is  array(l..c2)  of  buf»"index; 
type  buf  ♦•tol  ♦■pt  r  is  access  buf^-tbl  ; 
destination+'tbl  :  arrav(l..cl)  of  buf^-tblt-Ptr; 
buf  f  er^'ar  ray  i  array(l..c2)  of  strinq30; 

Procedure  forward(msa:  IN  message*-ot  r  ) ; 

end  0IG<-C0m; 


--  DC0V2  package  body 

pragma  en v i ronment (" ACS : TEXTIO .^LE" , "DCOM .mse int 1 0 . «SE " ) ; 
with  t  ex  t  i  O/ i  nt  i  o  ;  use  t  ex  t  ►i  o»  i  nt  i  o » asc  i  i  ; 

oackage  body  DIGICOM  is 


procedure  forwardlmsg  :  IN  messaQe«'Ot  r )  is 
i »  J  :  i nteger ; 
timer*>looo  :  integer; 
buffer«"index  :  buf*- index; 
line  J  bu  f  ♦-t  b  1  ♦•ot  r ; 
buf«-array  s  bufrtoi; 
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begin 

news'll  ne()» 

put*'30("number  of  iooos  to  t  i me*  .•••••")  ? 
get  ( 1 1  mer*-!  oop)  ? 
putml 0( "sendi ng. . . " ) » 
put (bel ) ? 

for  I  in  1  •  « 1 1  mer*-l OOP  looo 

line  js  dest  i  net  i  on^-tbl  (msg.dest  i  net  i  on)  ; 
buf^'erray  :=  line. all; 
i  :  s  1 ; 

while  buf  ♦'array  ( i  )  msg.connect  i  on  looo 

i :=  i  +  1 ; 

end  1  OOP* 

buffer^index  ;=  bu  f  ♦■array  ( i  )  ? 
bu  f  f  e  r^a  r  r  ay  ( bu  f  f  e  r^"  i  ndex  )  msg.dataf 

end  loop? 
out (be  1 ) * 

out«'20  ("  . .  .done  sending . ")» 

new*"  1  i  ne  ( )  » 
end  forward? 
end  D I SeCOM } 


mm 

••  0C0M2  driver  routine 

--  digital  communication  benchmark 
--  DC0M21 .EOO  on  disk 

--  timing  does  not  include  procedure  invocation  overhead 

—  26  Oct  1982 

pragma  env i ronment ( " 4CS : TEXTIO.MLE" . " INT 10 .mSE" . "OCQm .MSE " r 

"MAIN.MSE") ? 

with  text*"!  o»  i  nt  i  o»  0IG**C0*^? 
use  t  e X  t  i  o » i  n  t  i  0  f  0 1 GeCOM » asc  i  i  ? 

package  body  user^-oroceas*  I  is 
procedure  main  is 
i » j  ;  i nteger ? 
k  :  bufeindex? 
buf et  ab  1  e^Pt  r  :  buf  ^tbl  ♦■ot  r ; 
msgeout  :  messageeptr? 
forever  :  boolean  ;s  true? 
answer  :  character? 
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out*'30("chars*.  gdP  configuration,, 
new**!  i  ne ( ) » 

out^’BOf  "t  i*i  ng  does  not  include  oroc* 
-*  initialise  the  destination  table 
newel i ne ( ) 7 

oute30("init  destination  table . 

for  i  in  l,,ct  looo 
dest i nat i onetbl ( i )  new  bufetbl 7 
end  looo7 

**  initialize  a1 1  bufetbl's 

newel i ne ( ) 7 

outeSOCinit  bu  fet  b  t  '  s  . . 

for  i  in  l,,cl  looo 

buf et abl eeot p  :=  dest i nat i onetb I ( i ) 
for  i  in  1 . ,c2  I ooo 

buf et ab 1 eept r ( j )  57 

end  looo7 
end  1ooo7 

-•  initialize  buffer 
newel i ne  ( )  7 

oute20(“init  the  buffer . ")7 

for  k  in  l,,c2  1 ooo 

bu  f  f  erear  ray  (  k )  :s  . . 

end  looo7 

newel i ne ( ) 7 
while  forever  I ooo 

out e 1 0 ( "cont i nue?  ")7 

get (answer)  7 

exit  when  answer  s’n*; 

•nsgeout  :=  new  •ressaae? 

■nsgeout  ,si  2e  07 
newel i ne  ( )  7 

out  e20  ( "st  ar  t  digit  comm  7 

newe 1 i ne ( )  7 

outeSO ( "enter  destination^  conn, data, 
get ( msgeout .destination)7 
sk ioel i ne7 

get (msgeout .connection)) 
sk i oe I i ne7 

msgeout. data  : sget e| i nee30 ( )  7 


forward(msg*’out ) ! 
out«’20 ( "buf f af*  flush  is*.*..”) 
for  k  in  l..c2  iooo 
put(k)r 

put^’l  ine*'30(buffer*>arrav(k)) 
naw^'l  i  ne( )  * 
and  loop; 
skio*”!  ine? 
and  loop? 
nawfr 1 i na( ) > 

out*>20(''end  of  Jacoml . ")> 

end  main; 

and  usep«-orocass«*l ; 


•-  mEMI  Dackage  soec i f i cat i on 

--  MEMI  recursive  men'ory  test  oackaoe  soec  i  f  i  cat  i  on 

pragma  envi ronment ("ACS;TEXTIO,MLE"); 
with  te*t*'io;  use  te«t*-io; 
package  EAT4-MEM0RY  is 
size  :  constant  :s  50; 
i  :  integer  ;=0; 

tyoe  small^-table  is  array  ( 1 .  .si  ze)  of  character; 
type  sma  n  ♦•t  ab  1  e^'Ot  r  is  access  sma  1  1  rt  ab  1  e ; 

orocedure  FOREVER; 
end  EATrVEMORY; 


-“MEMI  oackage  body 

m  m 

--  MEMl  recursive  memory  test  body 

oragma  envi ronment  C " ACS : TEXT  1 0 , MLE" # "E A T . MSE " , " INT 1 0 . MSE " ) 
with  intio»text«"io; 
use  intio*text<*io; 

m  m 

package  body  EAT^memqry  i» 
procedure  FOREVER  is 

table^'otr  ;  smaH  rtabl  e^-ot  r; 
beg  i  n 

i  :=  i  +  1 ; 
out ( i  ) ; 
new*"  1  i  ne  ( ) ; 

table^-ptr  :=  new  small^-tabie; 

forever; 

end  forever; 
end  EATrVEMORY; 


--  MEMl  driver  routine 

““  MEMl  recursive  memory  test  driver  routine 
oragma  envi ronment ("ACS:TEXTIO.MLE"/"EAT,wse"» 

"main.mse")  ; 

with  te*  t  i  Or  EAT*"MEM0Ry ; 
use  t  e*  t  ♦•i  Of  E  ATrMEMQRY; 
oackage  body  user^-orocess*- 1  is 
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orocedure  main  is 


begin 

m 

put*-30("  start  of  eat 
FOREVER; 
end  main; 

nd  usereorocessel ; 


memory 
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—  VIEM2 


oackage  soec i f i cat i on 


•  •  MEM2  interative  fnemory  teat  oackage  soec  i  f  i  cat  i  on 

oraqma  env i  ron»»ent  ("ACSsTEXTIO,MLE")» 
with  text^-io;  use  te«teio» 
oackage  EAT^'MEmqRY  is 
si*®  i  Constant  :=  50} 
i  :  integer  ;s0} 

tvoe  small^-tabie  is  array  ( t ..  s  i  *e)  of  character; 
tyoe  swan  ♦•t  ab  1  erot  r  is  access  swalirtabie; 

orocedure  FQPEvER; 
end  EAT*.memORY; 


•-  mEm2  oackage  body 

«  m 

•-  m£M2  interative  memory  test  body 

«  m 

oraqma  env i ronmen t ( " ACS ; TEX T lO.MLE" , "E AT .MSE " , " INT  10 .MSE "  ) 
with  intio/textrio? 
use  intio.text*'io; 

«  «■ 

oackage  body  EATrMEyORY  is 
orocedure  FOREVER  is 

table«-otr  :  sma  11  rt  abl  e^ot  r ; 
infinite  :  boolean  :strue; 
begi  n 

while  infinite  looo; 
i  ;  =  i  ♦  1 ; 
out  ( i  ) ; 
new*- 1  i  ne  ( )  } 

table^'Otr  ;s  new  sma  1  1  ♦•t ab  1  e# 
end  looo* 
end  FOREVER; 
end  £AT*-meM0RY; 


--  MEV2  driver  routine 

..  yEM2  interative  memory  test  driver  routine 

oragma  environmentt"ACS;TEXTIO,MLE","EAT,MSE"* 

"MAIN.mSE"); 

with  te*t«-io»EAT«*MEMORY; 


1  OS 


use  t  ex  t  1  o»  E  AT^MEMORY  f 
package  body  usep»opoceas«-l  is 
Dpocedupe  main  is 

begi  n 

put^-SOi"  stapt  of  eat  memopy 
FOREVER; 
end  main; 

end  usep*-DPoceas*' I ; 


SEARCH 


-•  Courtesy  Prof,  Pat  tersoof Computer  Science  Division/ 

—  Deoartment  of  Electrical  Engineering  &  Computer  Sciences 
--  Univ.  of  California/  BerkeleV/CA, 

pragma  envi ronment ("ACS:TEXTIO.mlE"» "IHTIO.MSE" » "MAIN.MSE") 

with  te*t*-io/intio/ 

use  textei o/ i nt i O/asc i  i  « 

package  body  USER*-PROCESS«- 1  is 
procedure  MAIN  is 

type  strin  is  array ( i nteqer  range  1..120)  of  character; 
numi t erat i ons  t  integer; 
pos i t i on / ns / nk  :  integer; 

S/k  :  strin; 

function  STRSCH(s/k  :  IN  strin; 

ns/nk  :  IN  integer)  return  integer  is 

i/j  :  integer; 
base/ ksave/cont  :  integer; 
kend/ssave  :  integer; 
r  ;  integer; 


begi  n 

base  :s  i; 
ksave  ;=  i; 
cont  ;=  ns-nk+base; 
kend  ;=  ksave  ♦  nk«i; 
i  ;=  I ; 

I  ;=  i; 


<<too>> 

while  s(i)  k(i)  loop 
if  i  >=  cont  then 
r  :s  •i; 
goto  finish; 
end  i f ; 
i  :=  i  ♦! ; 
end  loop! 
ssave  : =  i ; 


i  : =  i*l! 

while  j  <=  kend  1 ooo 
i  ;  =  i  1 1 ; 

if  s(i)  /s  k(j)  then 
i  :s  ssave  *  i; 
j  ksave; 
goto  too; 
end  i f ; 


base  *  1 


i  j+i; 
end  loop; 
r  ;=  ssave  - 
<<f i ni sh>> 
return  (r); 
end  STRSCH; 

Begl  n 

s(l..<>0)  :s  "000000000000000000000000000000000000 
000000000000000000000000" ? 

8(61. .120)  ;=  "HEREOOOOOOOOOOOOOOOOOOOOOOOOOOHERE 
IS  A  MATCHOOOOOOQOOOOOOOO"; 
k(1..60)  :r  "HERE  IS  A  MATCH 

It  • 

lc(61..120)  ;=  " 

M  • 

$ 


1  OOP 

out«-1  i  06^30  (  "Berkel  ev  Character  Search  "); 

put*^30("A  of  )  ooos  to  time?..0  Exits 
get (numi terat  f  ons ) ; 

exit  when  numi t erat i ons  s  O; 
new*- 1  i  ne  ( )  J 
ns  ;=  120; 
nk  :=  IS; 
out (be  1) ; 

for  i  in  1 .  .nuiti  t erat  i ons  looo 
position  ;=  STRSCH(s# k/ns^nk ) ; 
end  loop; 
out ( be  1  ) ; 

out«-i  ine«-10("EN0  SEARCH"); 
out ( DOS i t i on ) ; 
end  loop; 
end  main; 

end  USER«-PR0CESS«-1 ; 
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SIEVE 


mm 

Courtesy  Prof.  Patterson#  Comouter  Science  Division 
-•  Department  of  Electrical  Enqineering  S  Computer  Sciences 
University  of  California#  Berkeley  CA, 

pragma  enwi ronment ("ACS: TEXT lO.MLE"# "INTIO.MSE"# 

-MAIN.MSE"); 

with  te*t*’io#intio# 
use  te* tfri o# i nt i o#asc i  i  ? 
package  body  USER«‘PPOCESS*‘l  is 
procedure  MAIN  is 
siie  :  constant  integer  :=  200; 
flags  !  array (0.  .si ze)  of  boolean# 
or  i  me  #  k  #count  #  1  ooo«'val  :  integer; 

m  m 

Begin 
1  OOP 

out*-30("S  of  loops  to  time?..0  exits  ")» 
get  ( 1  ooo^-va  1  )  > 
exit  when  looorval  =  O; 
new*-!  i  ne  ( ) » 
out (bel) ; 

for  iter  in  inteoer  range  1 . .  ( 1  ooo«-va  1  )  loop 
count  :=  0# 
for  i  in  0..size  loop 
f 1 ags ( i )  : =  t  rue » 
end  loop# 

for  i  in  0..size  I ooo 
if  f 1 ags ( i )  then 
prime  i  ♦  i  ♦  3# 
k  ;s  i  ♦  prime# 
while  k  <s  size  1 ooo 
f 1 ags(k)  :=  f al se» 
k  :=  k  ♦  prime# 
end  loop# 

count  ; s  count  +  1  # 
end  i f  # 
end  loop# 
end  loop# 
out (bel  ) ; 

out*-l  ine^-lOI"  End  Sieve")# 
out (count ) # 
out^l0("  Primes  ")» 
new*-l  i  ne  ( )  # 
end  loop# 
end  main; 

end  USER*-PR0CESS*-1  ; 
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ACKER 


--  Courtesy  Prof.  Pat terson, Computer  Science  Division, 

--  Oeoantment  of  Electrical  Enqineering  %  Computer  Sciences 
-•  Univ.  of  California,  Berkel ev,CA. 

pragma  environment  C" ACS : TEXriO.MLE*# • INT lO.MSE " , "MA IN. MSE" ) 

with  text*>io,  intio; 

use  t e« t mi o, i nt i 0, asc i i » 

packaoe  body  USERmPROCESSm 1  is 
procedure  MAIN  is 
a, i , arql , arq2  ;  integer; 

function  ACKER(*,y  :  IN  integer)  return  integer  is 
begin 

i f  X  s  0  t  hen 
return  (ytl), 
elsif  V  •  0  then 

return  ACKER ( x •  1 ,  I ) J 
el  se 

return  ACKER ( x- 1 , ACKER ( x , y- 1 )) ; 
end  i f  J 
end? 

m 

Begi  n 

putml inem20("Ackermann  Benchmark  • ) ? 
put  H  nem20  (  "  To  Exit,  Enter  0  ")? 

putml i nem30 ( "Begi n  time  when  bell  sounds  ")? 

'op® 

outml inem30("Enter  ACKER  Aguments  )» 

get (argl ) ? 

exit  when  argl  *  Of 
skipmj i ne? 
get (arg2) f 
out (be  1 ) f 

a  :=  ACKER (argl , arg2) ? 
out (bel); 

outml 0 ( "Cutout  of  "); 
out (argl ) ; 
out ( • ,  '  )  ; 
out ( arg2) ; 

newm 1 i ne ( ) ? 

out (a) ? 

newm 1 i ne ( ) ? 

end  loop? 

end  main; 

end  USERmPROCESSml ; 
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APPCNOIX  D 


CFA  BCNCHMARK  ALGORITHMS 

The  twelve  benehmaric  program  algorithm  descriptions 
used  in  the  first  CFA  study  follow,  A  more  detailed 
discussion  of  these  can  be  found  in  Reference  8, 

1.  I/O  INTERRUPT  KERNEL,  FOUR  PRIORITY  LEVELS 

The  Interrupt  Kernel  will  be  activated  by  an  I/O 
interrupt  with  priority  level  0,1,2  cr  3  from  one  of  four 
devices.  Actual  interrupt  processing  will  be  simulated  by 
counting  the  occurrences  of  each  type  of  Interrupt,  Higher 
level  Interrupts  will  be  able  to  Preempt  processing  of  lower 
priority  interrupts.  The  interrupt  handler  must  provide  for 
resumption  of  processing  of  the  preempted  lower  level 
interrupt  from  the  point  of  preemption,  as  much  processing 
as  possible  will  be  done  wltn  higher  priority  I/O  interrupts 
enabled. 

2.  I/O  INTERRUPT  KERNEL,  FIFO  PROCESSING 

The  interrupt  Kernel  will  be  activated  by  an  I/O 
interrupt  from  one  of  four  devices  which  will  be  placed  in  a 
service  gueue  for  f  Irst-ln-f  lrst>»out  (FIFO)  processing. 
Actual  interrupt  processing  will  be  simulated  by  counting 
the  occurrences  of  each  type  of  interrupt.  Space  should  be 


provided  to  handle  at  least  ten  queued  Interrupts  at  one 
time. 

3.  INPUT/OUTPUT  DEVICE  HANDLER 

After  an  I/O  request  is  Issued  by  an  application 
program,  and  after  the  executive  queues  an  input  control 
block,  this  test  program  is  Initiated  and  It  performs  the 
following  actions: 


1.  Check  status  of  the  tape  drive.  If  device  Is  busy 
exit.  If  the  device  Is  not  operable  branch  to  an 
error  routine.  If  the  device  Is  available,  set  uo 
and  Initiate  the  requested  transfer. 

2.  After  completion  of  the  transfer,  and  a  conse¬ 
quent  Interrupt,  the  device  handler  is  reentered 
and  the  following  processing  Is  performed: 

a.  store  status  information  (device  type  and 
Identification) , 

b.  If  transfer  was  unsuccessful,  abort  further 
processing, 

c.  If  a  successful  transfer  occurred  and  all  re¬ 
quested  transfers  accomplished  then  exit. 


The  application  programs  perform  hlgn  level  logical  I/O 
calls  that  cause  the  queuing. 


4.  FAST  FOURIER  TRANSFORM 

The  following  variables  are  used  in  the  algorithm: 

N:  The  number  of  data  points  0<s  n  <•  2**16, 

X:  A  vector  holding  the  N  samples  as  complex 
numbers . 

w:  A  vector  holding  the  first  n/2  powers  of  EXP(- 
2*P1*1*/N), 

work!  Auxiliary  working  storage. 


procedure  FFT(N,X,W} 

GROUPS  :s  N 

do  for  PASS  !s  0  by  steps  of  1  until 

lo<32(n)-l 

do  for  all  CLEMENT  sucb  that 

0  <»  element  <a  N/2 
"qenerate  complex  addend" 

WEXP  ta  0 
If  PASS  >  0 

then  WEXP  :=((ELEMENT*N)/2)  / 
2**PASS)  MOD  CN/2) 

end-lf 

If  WEXP  <>  0 

then  TFMPl  ja  X(ELEMENT+N/2)* 
W(EXP) 

else  TEMPI  :=  X(ELEMENT+N/2) 
end  If 

"generate  2  element  entries 
In  data  vector" 

XICELEMENT)  X(ELEMENT)  ♦ 

TEMPI 

XICELEMENT  +  N/2)  js  X(ELEMENT)  - 

TEMPI 

end-do 

If  PASS  <  Clog2(N)  -  n 
then 

"execute  perfect  card  shuffle 
on  data  vector" 

P  :3  2MMPASS 
GROUPS  !a  GROUPS/2 
do  for  all  I  such  that 

0  <a  I  <  GROUPS 
do  for  all  J  such  that 

0  <a  j  <  p 

INDEXl  :3  2*P*I  ♦  J 

1NDEX2  :a  P*I 

XCINDEXl)  :a  X1(INDCX2) 
X(INDEX1+P)  :3  XI (INDEX2+N/2) 
end-do 
end-do 

else 

do  for  all  1  such  that  0  <a  i  <  n 
X  ja  Xl(I) 
end-do 
end-lf 
end-do 
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5.  CHARACTER  SEARCH 


The  variables  used  In  this  algorithm  are: 


SRCHSTR  : 

SRCHLNGTH  : 
SRCHARG  ! 
ARGLNGTH  ! 
LOC  I 
WORK  : 


pointer  to  a  string  of  characters 

to  be  searched. 

length  of  that  string. 

pointer  to  a  string  of  characters. 

length  of  that  string. 

an  Integer  return  code. 

pointer  to  any  needed  storage. 


procedure  CHARSRCH (SRCHSTR, SRCHLNGTH, 

SRCHARG, ARGLNGTH, LOC > WORK) 


Integer  I 


LOC  :a  1 

do  for  all  1  such  that  0<s  I  <s  srchlngth-srcharg 

or  until  LOC  <>  -1 
If  the  substring  of  SRCHSTR  from  I  to 

14-ARGLNGTH-I  s  SRCHARG 

then  LOC  :a  1 

end-lf 

end-do 


6.  BIT  TEST,  SET,  OR  RESET 
The  variables  used  are: 


F  :  Function  code,  l*test,  2»  set,  3s  reset. 

N  :  Relative  bit  to  be  tested. 

Al:  Pointer  to  tightly  oacKed  bit  string. 

RC:  Return  code  Indicating  original  bit  status. 
WORK:  Pointer  to  any  needed  work  storage, 

procedure  bittest(f,n, ai ,rc,work) 

Integer  ABIT,D 

ABIT  :s  Al  ♦  N/(word  length) 

D  :s  N  mod  (word  length) 

If  D'th  bit  at  address  ABIT  *  i 
then  RC  :«  1 
else  RC  :*  0 
end-lf 
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If  F  a  2 

then  D'th  bit  at  address  ABIT  :s  i 
else  If  F  a  3 

then  D'th  bit  at  address  ABIT 
end-lf 

end-lf 


:a  0 


7.  RUNGE-KUTTA  INTEGRATION 

This  algorithm  solves  the  differential  equation  FCt,y)  a 
t+y  a  dy/dt  using  a  third  order  Runge-  Kiitta  integration. 
The  variables  used  are: 


TO  :  Initial  value  ot  T,  single  precision. 

YO  t  initial  value  of  Y,  single  precision, 

H  :  Interval  of  integration,  single  precision, 
TMAX:  Final  value  of  T,  single  precision, 

YMAX:  Final  value  of  Y  returned,  single  oreclslon. 


procedure  RUNGEKUTTACTO,  Y0,TMAX,  Y«4AX,W0RK) 
real  Kl,K2,K3 


YMAX  :a  YO 


do  for  all  T  from  TO  Incrmented  in  steps  of  H 

until  T  >  TMAX 

Kt  :a  H*(T+YMAX) 

K2  :a  H*(T  ♦  H/2  ♦  Y  ♦  Kl/2) 

K3  la  H  •  (T  ♦  3*H/4  ♦  Y  ♦  3*K2/4) 

YMAX  la  YMAX  ♦  2*Kl/9  ♦  K2/3  ♦  4SK3/9 
end-do 


8.  LINKED  LIST  INSERTION 

This  algorithm  inserts  an  element  into  a  doubly  linked 

list.  Variables  used  are: 

LISTCB  I  Pointer  to  a  list  control  block 
containing  t 

HEAD:  pointer  to  first  node. 

TAIL:  pointer  to  last  node. 

NUMENTRIES  :  number  of  entries. 

NEWENTRY:  pointer  to  new  entry  to  be  Inserted, 


118 


proctdure  LISTINSERTCLISTCB^NCWCNTRY) 

"the  notation  POZNTEP.FIELD  is  used  to  access  a 
particular  field  of  the  structure  ponted  to  by 
POINTER" 

pointer  PRESENT 
if  LXSTCP.NUMENTRIES  a  Q 

then  "list  is  empty,  so  initialize" 

LISTCB.HEAD  :a  LISTCB.TAIL  :a  NEWENTRY 

LISTCB.NUMENTRIES  :a  1 

NEWENTRY, NEXT  :a  NEWENTRY . PREV  la  0 


else 

"list  not  empty" 

PRESENT  ta  LISTCB.HEAD 

LISTCB.NUMENTRIES  :a  LISTCB.NUMENTRIES  t  1 
"determine  position  of  new  entry" 
while  NEW, KEY  >3  PRESENT, next  O  0  do 
PRESENT  ja  PRESENT. NEXT 
if  PRESENT, PREV  a  0  and  NEw.KEY  <  PRESENT, KEY 
then 

"new  list  head" 

LISTCB.HEAD  Ja  NEW 
NEW, PREV  :3  0 
PRESENT. PREV  :a  NEW 
NEW, NEXT  {a  PRESENT 

else 

if  NEW.KEY  3>  PRESENT. KEY 
then 

"new  list  tall" 

PRESENT. NEXT  ta  LISTCB.TAIL  :a  NEW 
NEW, NEXT  :a  0 
NEW. PREV  :a  PRESENT 
else 

"Insert  in  middle" 

NEW, NEXT  :a  PRESENT 

NEW, PREV  *3  PRESENT, PREV 

PRESENT. PREV  |a  NEW 

"bacK  up  and  linK  with  predecessor" 

PRESENT  |a  NEW, PREV 
PRESENT. NEXT  }«  NEW 
end«lf 
end-lf 
end«lf 
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9.  QUICKSORT 


This  algorithm  performs  a  quicksort  on  an  array  of 
records.  The  variable  used  are: 


N  I  The  number  of  records  to  be  sorted. 

M  :  Integer  oarameter  specifying  the  changeover 

point  between  quicksort  and  a  simple  Insertion. 
REC  t  Pointer  or  the  first  element  of  the 
array  to  be  sorted. 

WORK:  pointer  to  any  needed  woriclng  storage. 

procedure  QUICKSORT (N, REC, M, WORK) 

Integer  L,R,I,J,K 

Integer  array  STACKto:2*f (N)-i] 

character  string  v 

RECCN+l]  :*  infinite 
L  ts  1;  R  :3  N 
do  forever 

I  :a  L:  j:s  r+i  j  v  :=  RECID 
do  forever 

do  I  :*  Itl  until  RECtI]  *>  V  end-do 
do  until  RECCJ)  <a  V  end-do 

If  J>  I 

then  swap  RECCI)  with  RECCJJ 
else  ooto  end-first 
end-lf 
end-do 
end-first: 

swep  PECCLJ  with  RECCJI 

If  both  subfile  sizes  (J-L  and  R-J)  <»  R 

then 

If  stacK  empty 

then  goto  end-outer 
else  poo  L  and  R  from  stacK 
end  If 
else 

if  smaller  subfile  size  <>  M 

then  set  L  and  R  to  lower  and  upper 
limits  of  laroer  supflie 
else  push  lower  and  upper  limits  of 
larger  subfile  onto  stacic 
set  L  and  R  to  limits  of  smaller 
subfile 

end-lf 
end-lf 
end-do 
end-outer : 
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do  for  I  from  N-1  to  1  in  sops  of  1 
if  PECtI]  >  RECI<»>i]  then 
V  js  REC[11;  J  t«I+i 
do  forever 

RECCJ-1]  !3  RECfJJ  t  J 

If  REC[J]  a>  V  then  goto  end-last  end-lf 
end-do 

end-last:  A[J-1]  :s  v 
end-lf 
end-do 


10.  ASCII  TO  FLOATING  POINT  CONVERSION 

The  following  variables  are  used  in  this  algorithm: 


N  :  Number  of  characters  In  the  string. 

A1  :  Address  of  the  character  string. 

A2  :  Address  of  floating  oolnt  number  where  the 
result  will  be  placed. 

procedure  afp(N,ai,A2) 

Integer  number,  position 

real  RESULT,  DIVISOR 
boolean  ISNEGATIVE 

ISNEGATIVE  false 
POSITION  :*  0 

If  first  character  of  ai  is  a  sign  character 
then 

If  sign  character  Is 

then  ISNEGATIVE  :s  true 
end-lf 

POSITION  ;a  1 
end-lf 

NUMBER  :*  integer  equivalent  of  characters 
POSITION  to  j-1  of  Al  where 
character  J  of  Al  Is 
RESULT  :a  floating  point  equivalent  of 
NUMBER 

"  the  following  two  steos  can  be  done  In 
parallel  If  desired" 

NUMBER  :»  Integer  equivalent  of  characters  J+l 
to  N  of  Al 

DIVISOR  :*  floating  equivalent  of  10m*(n-J) 

A2  :s  RESULT  f  (floating  oolnt  equivalent  of 

NUMBER)  /  DIVISOR 


11.  BOOLEAN  MATRIX  TRANSPOSE 

The  following  variables  were  used  In  this  algorithm: 

A1  :  Pointer  to  a  word  of  storage. 

A2  :  bit  number  within  word  Al  where 
the  matrix  begins. 

N  I  size  of  the  boolean  matrix. 

procedure  BMT(N,ai.a2) 

Integer  l,J 

boolean  BCl:N/l:N}  beginning  at  bit  A2  of  word  Al 
do  for  all  I  and  J  such  that  (i<a  J  <=  N) 

and  (J+l  <a  I  <a  N) 

swap  BCIfJ]  and  BCJ^Il 
end-do 


12.  VIRTUAL  MEMORY  SPACE  EXCHANGE 

This  algorithm  performed  a  virtual  memory  space  exchange 
through  the  use  of  a  supervisor  call.  There  are  two 
functions  which  must  be  provided  by  the  algorithm, 

1.  CALL:  saves  enough  Information  to  restore  the  en¬ 
tire  state  of  the  caller. 

2.  RETURN:  restores  the  environment  active  before 
the  previous  call. 

The  sixteen  benchmarx  programs  written  by  the  second  CFA 
study  group  follow,  a  complete  discussion  of  them  can  be 
found  In  reference  1, 


1,  terminal  INPUT  DRIVER 


This  algorithm  inputs  one 

line  of  ASCII 

characters 

from 

a  terminal 

device. 

ASCII 

rubouts  should 

delete 

the 

character,  a 

carriage 

return 

terminates 

the 

line. 

The 

program  need  not  be  reentrant. 
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Algorlthfflt  A  subroutine  TTYXNCBUFFCR)  Initiates  the 
transfer.  It  has  a  single  reference  parameter^  the 
buffer  to  be  filled.  The  buffer  consists  of: 


ADDRESS  TERMADDR 
character  CBUFtl:?] 

The  buffer  is  assumed  to  be  large  enough  for  the 
line.  The  transfer  Is  started  and  the  routine  re¬ 
turns,  The  Interrupt  service  routine  collects  the 
line  In  some  machine  dependent  manner.  The  terminal 
Interface  Is  assumed  to  oe  a  minimal  one.  (it  does 
the  serlal-oarallel  conversion),  when  a  carriage  re¬ 
turn  Is  entered,  the  terminal  Input  Is  disconnected 
and  a  transfer  to  the  buffer  TERMador  is  made. 


2.  MESSAGE  BUFFERING  AND  TRANSMISSION 

This  algorithm  queues  a  message  buffer  and  the 
transmits  the  message  over  a  DMA  llnic  In  FIFO  order. 


RECORD  BUFR(ADDRESS  NEXT,  ADDRESS  TERMADDR, 

INTEGER  SIZE, INTEGER  DATA C 1 J SIZE) ) ) 
POINTER  BUFR  END, START 
ADDRESS  TEMP; 

•QUEUE  SUBROUTINE 

PROCEDURE  OUEUECREFERENCE  BUFFER)* 

BEGIN 

IF  START  NEO  0  THEN  END, NEXT  <-  ADDRESS ( BUFFER )  FI; 
END  <-  ADDRESS(BUFFER) ; 

JOUIT  IF  CHANNEL  ALREADY  RUNNING 
IF  START  NEQ  0  THEN  RETURN 
ELSE 

START  <•  ADDRESSCBUFFER) ; 

TEMP  <-  0; 

GOTO  RESTART 

FI; 

END; 

INTERRUPT! 

BEGIN 
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!  Programmers  should  insert  here  device  and 

i  machine  dependent  code  to  terminate  the 

1  device  transfer 

TEMP  <-  START. TERMAODRI 

START  <-  START. NEXT; 

restart: 

IF  START  ■  0 
THEN 

GO  TO  TEMP 
ELSE 

!  programmers  should  insert  here  device  and 
I  machine  deoendent  code  to  Initiate  the 
I  device  transfer. 

FI  I 

IF  TEMP  s  0 
THEN  RETURN 
ELSE  GO  TO  TEMP 
FI 
END 


3,  MULTIPLE  PRIORITY  INTERRUPT  HANDLER 

This  test  program  Is  desloned  to  process  interrupts  from 
four  devices  in  priority  order.  Upon  receiving  an  interrupt, 
the  processor  will  branch  to  the  approoriate  device  service 
routine.  All  interrupts  from  lower  priority  devices  will  be 
disabled.  Device  priority  is  egual  to  device  number,  device 
number  l  has  lowest  priority,  device  4  has  highest.  After 
the  device  deoendent  service  the  device  ID  Is  added  to  the 
executive  queue  for  user  scheduling  purposes.  This  program 
need  not  be  reentrant.  Each  device  service  routine  will  be 
simulated  by  the  algorithm  below. 


JDEVICE  SERVICE  ROUTINE  INTEGER  OWN  A;  FOR  I  <a  I  TO 
AC0t2]  DO  A  <-  (A*999)  MOO  123757  OD; 
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4.  VIRTUAL  MEMORY  SPACE  EXCHANGE 


TMs  algorithm  will  Involve  a  suparviiory  call  handler 
which  will  provide  the  functions  "call"  and  "return".  The 
supervisor  Is  to  Implement  protected  procedure  calls  with 
parameters,  "call"  will  select  Index  into  a  table  of  address 
space  descriptors  maintained  by  the  supervisor.  The  "call" 
performs  the  following: 


1.  save  the  caller's  state. 

2.  Determine  the  callee's  address  space. 

3.  Set  up  the  memory  mapping  and  protection  to  ac¬ 
cess  the  callee's  address  space. 

The  "return"  function  takes  no  parameters.  It  re¬ 
stores  the  environment  active  before  the  orevlous 
call. 


5.  SCALE  VECTOR  DISPLAY 

This  algorithm  scales  a  list  of  graphic  vectors  about  a 
given  center.  The  vectors  are  represented  as: 


function  4  bits 

X  coordinate  12  bits 

Intensity  4  bits 

y  coordinate  12  bits 

PROCEDURE  SCALEADJUSTCREF  DLIST, VALUE  LEN. 

VALUE  XCENTR,  VALUE  YCENTR, 
VALUE  SCALE)* 

BEGIN 

10  LEO  XCENTR.  YCENTR  LEO  2047 
tSCALE  IS  THE  ACTUAL  SCALE  FACTOR  TIMES  128 
INTEGER  LEN.XCENTR, YCENTR. SCALE, I. XTMP.YTMP; 
RECORD  VECT0R{INT4  FUNCT.INT  12  X,  INT4  INTEN. 
INT  12  Y); 

VECTOR  DLZSTCl :LEN) y 
FOR  I  <-  1  TO  LEN  DO 
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XTMP  <-  OLIST.XCIIOSCALEI 

YTMP  <-  dlist,ycii»scale; 

IF  DLIST.FUNCTCIl  NEO  0 
THEN 

XTMp  <-  XTMP+XCEMTR*(128-SCALE) ; 
YTEMP  <-  YTEMP+YCENTR*(128-SCALE) ; 
FI; 

DLIST.XCIJ  <-  XTMP/128; 

DLIST.YCIl  <-  YTMP/128; 

OD; 

RETURN 

END 


6,  ARRAY  ‘•(Ai^IPULATION  -  LU  DECOMPOSITIO.V 

This  alqorlthin  factors  a  square  matrix  Into  an  upper  and 
lower  triangular  matrix. 


LUOFCOMPCREFEPENCE  A,  VALUE  N)b 
BEGIN 

REAL  ARRAY  An:N,l:N]  f 
REAL  MULT; 

INTEGER  DIAG,  ROW,  COL; 

FOR  DIAG  <al,  N-1  DO 
FOR  ROW  <s  DIAG^1,<V  DO 

A[R0W,0IAG1<-  MULT<«  A  CROW , DIAG } /A [DIAG , 01  AG] 
FOR  COL  <a  DIAG+1,N  DO 
A tPOW,COL]<aA  CROW , COL J -MULT*A CDI AG , COL] 

OD 

OD 

00 

END 


7,  TARGET  TRACKING 

This  algorithm  taxes 
object  and  finds  In  a 
closest  entry. 


the  coordinates  of  an  unknown 
table  sorted  by  x  coordinate  the 


PROCEDURE  TARGETCPEFERENCE  TABLE,  VALUE  LEN,  VALUE  X 

VALUE  Y,  REF'^RENCE  FOUNDJs 

BEGIN 

INTEGER  LEN, START, END, MID, UP, DOWN; 
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REAL  MINDIST; 

ADDRESS  FOUND 

RECORD  TENTPYCREAL  X,  REAL  Y,  REAL  DAT1,REAL  DAT2); 
TENTRY  TABLEtllLEN] 

START  <-  1|  END  <-  LEN; 

WHILE  START  <-  END  DO 
MID  <-  (STAPT+END)/2 
IF  TABLE, X[MID3  <  X 
THEN 

START  <-  MID+1 
ELSE 

END  <-  MID 
FI 
00; 

iConpute  distance  of  nearest  x  entry 
MINDIST  <-  OISTCTABLEtMIDl ,X,Y) ; 

FOUND  <-  ADDRESS(TA8LEtMIDJ ) ; 

Isearch  neighborhood  for  a  nearer  entry 
UP  <-  MID-*-!?  DOWN  <-  MID-1? 

WHILE  UP>0  OR  DOWN  >0  DO 
IF  UP>0  THEN  CHECK(UP);  Up<-  UP  ♦1  FI? 

IF  DOWN  >0  THEN  CHECKCDOWN)?  DOWN<-OOWN«l  FI? 

OD? 

RETURN? 

iChecX  an  individual  entry  against  closest  found 

PROCEDUPE-MACPO  CHECKCJ)  a 

BEGIN 

IF  J<1  OR  J>LEN  OR  ABS (TABLE, X tJ3 -X)  >«  MINDIST 
THEN  J  <«0  ?  RETURN  FI? 

IF  DISTCTABLECJ] »X,Y)  <  MlNDIST 
THEN 

MINDIST  <-  DISTCTABLECJl ,X,Y)? 

FOUND  <-  ADDRES5(TABLECJJ ) 

FI? 

RETURN 

END 

1  DISK)  Is  the  metric  defined  in  the  problem 
END 


8.  DIGITAL  COMMUNICATIONS  PROCESSING 

This  algorithm  Is  given  a  message  with  a  header  which 
contains  the  destination  and  connection  ID,  and  places  the 
message  In  the  appropriate  transmission  line's  output 
buffer. 


127 


PROCEDURE  FORWARDCREFERENCE  MSG)  s 
BEGIN 

RECORD  MESSAGECINTie  CID^INTIS  DEST,  INT16  SIZE 
CHARACTER  MSGIlJ?)); 
BUFTABLECINTEGER  CID, ADDRESS  BUFFER); 

MESSAGE  MSG; 

POINTER  BUFTAPLE  LINE; 

EXTERNAL  ADDRESS  DESTABLE Cl t ?] ; 

!Flnd  BUFFER  table  for  destination  line 
LINE  <•  DESTABLECMSG.DEST)  ; 

IFlnd  ring  buffer  for  this  connection 
I  <-  l; 

WHILE  LINE.CIDCI)  NEQ  MSG. CIO 
DO  I  <-  I  ♦  1  OD; 

BUFFER  <-  LINE, BUFFER  Cl)  ; 
iCopy  the  message  to  the  buffer 
MOVE (ADDRESS (MSG) , BUFFER, MSG, SIZE); 

RETURN 

END 


9.  HASH  TABLE  SEARCH 

This  program  locates  the  position  a  Key  would  occupy  in 
a  hash  table, 

PROCEDURE  HASHLOOKCREFEPENCE  TABLE,  VALUE  SIZE, 

VALUE  KEY,  REFERENCE  POSITION, 
REFERENCE  FULL)  s 

BEGIN 

ADDRESS  POSITION 
INTEGER  SIZE, KEY, check; 

BOOLEAN  FULL; 

RECORD  TENTRYC INTEGER  KEY,  INTEGER  DATA); 

TENTRY  TABLECO;SIZE-n  ; 

ICompute  first  place  to  looK 
CHECK  <-  KEY  MOD  SIZE; 

FULL  <-  FALSE; 

FOR  I  <-  1  TO  SIZE/2  DO 

IF  TABLE. KEYCCHECK]  a  KEY  OR  TABLE , KEY CCHECK]  a  0 
THEN 

POSITION  <-  ADDRESS(TA3LE,KEY CCKECK) ) ; 

RETURN 

FI; 

CHECK  <-  (CHECK  t  I)  MOD  SIZE 
OD 

FULL  <-  TRUE 

RETURN 

END 
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10.  LINKED  LIST  INSERTION 

This  slQorlthni  Inserts  •  node  in  an  ordered  doubly 
linked  list. 


PROCEDURE  LISTINSERTCVALUE  LISTCB,  VALUE  NEWENT  Y)s 
BEGIN 

RECORD  LCBCAODRESS  HEAD,  ADDRESS  TAIL, 
integer  NUMENTRIES); 

RECORD  LISTENTRY(INT32  KEY, ADDRESS  NEXT, ADDRESS  PREV) 
POINTER  LCR  LISTCB,* 

POINTER  LISTENTRY,  NEWENTRY , PRESENT ; 

IF  LISTCB. NUMENTRIES  a  0 
THEN 

LISTCe.HEAD  <-  LISTCB. TAIL  <-  NEkENTRY; 

LISTCB. NUMENTRIES  <-  1; 

NEWENTPY.NEXT  <-  NEWENTRY , PREV  <-  0 
ELSE 

PRESENT  <-  LISTCB. HEAD; 

LISTCB.  NIJMENTPIES  <-  LISTCB.  NUMENTRIES+1 ; 

WHILE  NEWENTRY.KEY  GEO  PRESENT. KEY  AND 

PRESENT. NEXT  NEO  0 
DO  PRESENT  <-  PRESENT. NEXT  OD; 

IF  PRESENT. PREV  aO  AND  NEWENTRY.KEY  <  PRESENT, KEY 
THEN 

LISTCB, HEAD  <•  NEWENTRY; 

NEWENTRY,PREV  <-  0; 

PRESENT, PREV  <-  NEWENTRY 
NEWENTRY, NEXT  <-  PRESENT; 

ELSE 

IF  NEWENTRY, KEY  GEO  PRESENT, KEY 
THEN 

PRESENT, NEXT  <-  LISTCB, TAIL  <-  NEWENTRY; 

NEWENTRY. NFXT  <-  0; 

NEWENTRY, PREV  <-  PRESENT 
ELSE 

NEWENTRY, NEXT  <-  PRESENT; 

NEWENTRY, PREV  <-  PRESENT, PREV; 

PRESENT, PREV  <-  NEWENTRY; 

PRESENT  <-  NEWENTRY, PREV; 

PRESENT, NEXT  <-  NEWENTRY 
FI 
FI 
FI 

RETURN 

END 
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11.  PRESORT  ON  A  LARGE  ADDRESS  SPACE 

This  algorithm  takes  an  array  of  records  in  random 
order  and  rearranges  them  to  form  a  heap.  The  heap  is  a 
binary  tree  in  which  each  node  is  greater  than  or  equal  to 
its  descendenti. 


HEAPIFYCREFERENCE  REC, VALUE  N)s 
BEGIN 

INTEGER  ARRAY  RECtUN]; 

INTEGER  CHECK,  NEW; 

FOR  NEW  <-  2,  N  00 
CHECK  <-  NEW; 

WHILE  CHECK  NEQ  1  AND  RECtCHECK]  >  RECtCHECK/2] 
DO 

RECCCHECK]  <»>  RECtCHECK/23 ; 

CHECK  <-  CHECK/2 
OD 
OD 
END 


12.  AUTQCORRELATE  ON  A  LARGE  ADDRESS  SPACE 

This  algorithm  computes  the  autocorrelation  of  the 
vector  A  from  i  to  T, 


PROCEhURE  AUTOCREFERENCE  A,  VALUE  V, VALUE  T, 
REFERENCE  RES)* 

BEGIN 

INTEGER  N,T,TAU; 

REAL  ACllN] ,  RESCliT] ) 

FOR  I  <-  I  TO  T  DO  RES  Cl)  <-  0  OD; 

FOR  I  <-  1  TO  N  DO 
FOR  TAU  <-  1  TO  T  DO 

IF  I  ♦  TAU-1  >  N  THEN  EXITLOOP  FI; 
RESCTAU)  <-  RESCTAU)  ♦  A tX) RA tI+IAU-1) ; 
OD 
OD 

RETURN 

END 


13.  CHARACTER  SEARCH 


This  algorithm  searches  a  given  string  to  see  if  It 
contains  a  substring  that  exactly  matches  the  given  argument 
string. 


PROCEDURE  CHARSRCHCREP  SRCHSTR,  VALUE  SRCHLNGTH, 

REF  SRCHARG,  VALUE  ARGLNGTH,REF  LOO* 

BEGIN 

INTEGER  l.SRCHLNGTH,  ARGLNGTH; 

BYTEVECTOR  SRCHSTR CO :SRCHLNGTH-l 3 , SRCHARG CO : ARGLNGTH-1 3 
LOC  <-  *1; 

IF  ARGLNGTH  LEO  0  THEN  LOC  <-  0;  RETURN  FI; 

FOR  I  IN  0,SRCHLNGTH-ARGLNGTH  DO 

IF  SRCHSTRC1;I+ARGLNGTH3  LEO  SRCHARG 
THEN  LOC  <-  l;  RETURN  FT; 

00; 

RETURN 

END 


14,  BOOLEAN  .MATRIX  TRANSPOSE 

This  algorithm  computes  the  transpose  of  a  given  N  by  N 
matrix  In  place. 


PROCEDURE  BMTCVAL  N.VAL  Al,  VAL  A2)  a 
BEGIN 

integer  I,J; 

BOOLEAN  BC1:N,1|N3 
FOR  1  IN  l,N-l  ;  J  IN  I+l,N  DO 
BCI,J3  <«>  BCJ,I3 
OD 

RETURN 

END 
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15.  RECORD  unpacking 

This  algorithm  unpacks  the  fields  of  a  record  into  af^n 
integer  array. 


PROCEDURE  UNPACKCREF  RECORD,  REF  FQRHAT,  VALUE  LEN 

REF  RESULT)* 

BEGIN 

BITSTRING  RECORDtOi?}; 

INTEGER  LEN, START, RESULT  Cl: LEN] , TEMP, I; 

ARBTYPE  F0RMATC1:LEN]  : 

START  <•  0 

FOR  I  <-  1  TO  LEN  DO 

TEMP  <-  PECaRDCSTART:START^FQRMAXri3-13 ; 

START  START  +  FQRMATtT]? 

IF  FORMATtl]  IS  A  DISTINGUISHED  VALUE 
THEN 

TEMP  <.  SIGNNEXTENDCTEMP) 

FI: 

RESULTCI)  <-  TEMP: 

OD; 

RETURN 

END 


16,  VECTOR  TO  SCAN  LINE  CONVERSION 

This  algorithm  takes  a  list  of  vectors  and  produces  a 
raster  scan  line  conversion. 


PROCEDURE  VECSCANCREF  DLIST, VALUE  LEN,  REF  TEMP)* 

BEGIN 

RECORD  OI5PLAYCINT16  XS,  INT16  YS,  INT16  XE,  INT16  YE), 
WORKLISTCINTIS  XS,INT16  XE,1NT32  Y,INT32  SLOPE): 
DISPLAY  DLlSTrilLEN] 

WORKLIST  TEMPCl !LEN*l] : 

INTEGER  I,  START,  LINE,  DENOH; 

BITSTRING  BITfl:l0243: 

IGenerate  working  vector 
FOR  I  <-  1  TO  LEN  DO 

TEMP,XSCI3  <-  DLIST, XSCI): 

TCMP,XE  <-  DLIST, XEfZ3; 

TEMP,YC13  <-  DLIST, YStI)*l024: 

DENOM  <•  (DLIST. XECIl  -  DLIST, XStI3  T  1): 
TEMP,SLOPE(I3  <•  (DLIST, YE CI3 -DLIST, YS CI3 ) 41024/OENOM 


132 


TEMP,XStLEN+l]  <-  1025 
!  G«nerate  the  scan  Image 
ST^RT  <-  U 

FOR  LZNF  <-  1  TO  1024  DO 
BIT  <-  0 

I  <-  start? 

WHILE  TEMP.XStl]  LEO  LINE  DO 
FOR  K  <-  TEMP.Y[I1/1024  TO  (TEMP.YCll  t 

TEMP.SLOPECI) )/1024 

DO  BITtKl  <-  I  OD; 

TEMP.Ytl]  <-  TEMP.YCll  ♦  TEMP.SLOPECI]? 

IF  TEMP.XEtl]  *  LINE 

THEN  TEMPCSTART]  <*>  TEMPCll? 

START  <-  START  *  1; 

FI; 

I  <-  I  ♦  1? 

OD? 

OD 

RETURN 

end 


APPENDIX  E 


CDS  432/670  USERS  MANUAL 


The  following  Is  an  effort  to  enable  someone  with  no 
prior  knowledge  of  the  432/600  system  to  be  able  to  compile, 
link,  and  execute  programs  on  the  432  in  a  minimum  amount  of 
time  and  'fuss',  A  knowledge  of  ADA  is  assumed,  as  is 
familiarity  with  VMS  (e.g,  tne  vms  editor). 

Referring  back  to  Flguret6)  It  can  be  seen  that  a 
variety  of  hardware  and  software  Is  Involved  in  simply 
getting  a  program  to  'run'  on  the  432,  This  variety  of 
needed  hardware/software  is  collectively  referred  to  as  the 
432  "Cross  Development  System",  or  "CDS"  for  short.  Not 
surpr islndly ,  those  functions  needed  first  in  order  to 
achieve  the  desired  result  of  a  program  executing  on  the  432 
are  accomplished  on  tne  VAX  11/780  host.  Briefly,  the  steps 
reoulred,oius  their  CDS  'companion  elements'  are: 


1.  Program  Creation/Editing 

2.  Compilation 

3.  Linking 

4.  Downloading 

5.  Program  Load/Cxecutlon 


VAX/VMS 
VAX/VMS 
VAX/VMS 
MDS  800 
MDS  800/432 
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1.  PROGRAM  CREATZON/EOITING 

Creation  of  a  login  file  with  at  least  the  following 
commands  will  substantially  add  to  the  ease  of  your  terminal 
sessions  while  woriclna  with  those  CDS  parts  which  reside  on 
the  VAX/VMS  host: 

SADA4a2 

smopo  del  *,mso; *+»,mbo;* 

Smooc  :=a  del  ♦.msc; ♦♦*,mbc; * 

smope  :s*  del  »,mse;*'*'*,mbe;* 

The  reason  for  these  commands  will  become  evident  as  we 
continue, 

ADA  source  files  to  be  complied  by  the  Intel  ADA  cross 
compiler  must  have  a  file  extension  type  of  either: 

1.  <f llename>.MSS  =>  An  ADA  source  specification 
file. 

2.  <f ilename>,M8S  s>  An  ADA  source  body  file, 

3.  <f llename>,MCS  *>  Both  specification  and  body. 

In  our  opinion,  dividing  source  code  Into  separate 
specification  C.msS}  and  body  (.MSS)  flies  was  In  keeping 
with  some  of  the  original  philosophies  behind  ADA,  l,e., 
encapsulation  and  information  hiding.  Unfortunately,  the 
compilation  efforts,  of  necessity,  must  double  (2  files  to 
compile  vs,  i  In  the  mcs  case),  what  follows  next  are 
figures  of  a  sample  program.  Figure  19  Illustrates  the 
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division  into  specification  and  body.  Figure  20  Illustrates 
the  combined  (MCS5  format.  Besides  the  distinction  of 
woriclng  with  two  separate  flies  as  opoosed  to  one,  tatce 
special  note  of  the  line,  common  to  tne  'body',  which  begins 
with  "pragma  environment,..". 


I 

I  pacwage  EXAMPLE!  Is  i 
I  procedure  SIMPLE?  i 
I  end  EXAMPLE!?  I 

t-— 

A 

t  The  specification  filed  as  EXAMPLE!. MSS 

I  The  body  filed  as  EXAMPLE!, MBS  I 
V  V 

pragma  environment ( "ACS? textio.mle" , "EXAMPLE! .msE" , 

"INTIO.MSE"  )  ? 

With  text.lo, Intlo? 
use  text«lo, Intio, ascii? 
oacxage  body  EXAMplei  is 
procedure  SIMPLE  Is 

m  m 

x,y,z  :  Integer? 

m  m 

Begin 

X  : 3  10? 

y  IS  15? 

put-llne.lOC "  SIMPLE  ")? 
outCbei! ? 

--  this  rings  the  bell, 'use  ascl 1 'enables  this 
z  :=  x+y? 

put(z)?  -•  'Intto'  allows  you  to  do  this 
putCbei) ? 

pUt.llne.lO("END  SIMPLE")? 
end  SIMPLE? 
end  EXAMPLE!? 


Figure  19,  Specification  and  Body  Format  (Separate) 
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pragma  environment ("ACStTEXTIO.MLE", "INTIO.MSE" ) ; 
with  text.lOflntlo; 
use  text.lo, Intlor 

mm 

oackage  EXAMPLE2  Is 
procedure  simple; 
end  EXAMPLE2; 


oackage  body  EXAMPLE2  Is 
orocedure  simple  Is 

x,y,z  I  Integer; 

mm 

Begin 
X  :a  10; 

y  *  ~  IS; 

PuLllne.lOC  SIMPLE  ")f 
put(bel) ; 
z  :s  x+y; 
put(z) ; 

Put«llne«10C"END  SIMPLE"); 
end  SIMPLE; 
end  EXAMPLE2; 

Combined  specification  and  body  filed  as 
EXAMPLE2.MCS. 


Floure  20,  A  Combined  Format  Examole 


Information  is  conveyed  to  the  ADA  compiler  system  by 
means  of  pragmas.  The  environment  pragma  soeclfles  the  names 
of  external  environment  flies  (or  library  units)  that 
constitute  the  compilation  environment  for  the  current 
compilation  unlt(s).  If  the  current  compilation  depends  on 
other  compilation  units  from  other  compilations,  then  the 
environment  flies  from  these  compilations  must  be  listed  in 
the  ENVIPONMENT  pragma  in  the  current  compilation.  These 
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environment  pragmas  enable  separate  compilation  while  still 
maintaining  strong  type  checking  of  Interfaces,  two  features 
which  ADA  is  supposed  to  fulfill.  In  these  examples  the 
compilation  of  the  body  depends  ont 

—  ACSiTEXTZO.MLE  3>  so  the  package  can  perform 
character  I/O, 

--  INTIQ.MSE  a>  SO  the  package  can  perform  Integer 
I/O. 

••  EXAMPLEl.MSE  *>  the  corresponding  specification 

file. 

To  alleviate  confusion  on  file  extensions,  the  following 
Is  a  list  of  VMS  file  extensions  used  In  the  432  ADA 
Compiler  System  (ACSl. 

1.  First  character: 

M  —  The  file  contains  a  library  unit,  m  stands 
for  module. 

S  --  The  file  contains  a  SEPARATE  stub. 

2.  Second  Character: 

S  --  The  file  contains  a  program  unit  specifica¬ 
tion. 

B  --  The  file  contains  a  program  unit  body. 

C  --  The  file  contains  the  combination  of  a  pro¬ 
gram  unit  specification  and  a  prooram  unit 
body. 

L  --  The  file  Is  a  program  Horary  file  supplied 
by  Intel. 

3.  Third  (last)  Character: 

S  -•  The  file  Is  an  ADA  source  text  file. 
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C  •>  The  file  is  an  environment  file 


R  —  The  file  Is  a  REPORT  file. 

0  -•  The  file  Is  an  object  code  (EOD)  file. 

L  •-  The  file  Is  a  REPORT  listing  file. 

C  ••  The  file  Is  an  object  code  listing  file. 

M  The  file  Is  a  specification  file  for  the 

COMBINE  utility  and  contains  a  list  of  en¬ 
vironment  flies  that  are  to  be  meroed, 

I  --  The  file  is  an  integrated  environment  file 
created  by  the  COMBINE  utility. 

T  --  The  file  Is  a  listing  file  produced  by  COM¬ 
BINE  and  contains  the  file  table  listing  of 

the  Integrated  environment. 


For  added  clarification: 


e.g.  <f llename>.MSS  —  An  ADA  source  text  file 
which  corresponds  to  a  specification. 

e.g.  <f llename>«MBS  —  An  ADA  source  file  contain¬ 
ing  program  unit  bodies. 

e.g,  TEXTIO.MLE  --  A  library  environment  file  sup¬ 
plied  by  Intel. 


2.  COMPILATION  ^ 

The  Intel  comoller  Is  Invoiced  by  the  command 
"IDA",  followed  by  the  filename.  If  the  filename  is 
omitted/  the  compiler  will  prompt  for  It.  Our  Input  to  the 
compiler  consisted  either  of  <f llename,MSS>/  for 
specification  flles/  or  <f liename.MBS>/  for  the 
implementation/  l.e.,  body/  files.  Output  from  a  successful 
compilation  consists  of  files  of  type: 


1.  .MBS  or  .MSE  •-  The  environment  file  represen¬ 
tation. 

2.  .HBC  or  «MSC  —  The  object  code  listing  file. 
It  is  utilized  when  debugging  on  the  432, 

3.  ,MBO  or  .MSO  --  The  object  code.  This  is  input 
to  the  linking  process. 


Unsuccessful  compilation  results  in  flies  of  the  type: 


1.  ,M8L  or  .MSL  --  A  report  listing  file,  we  gen¬ 
erally  never  used  this. 

2.  ,MBR  or  ,MSR  --  A  file  which  when  prefixed  by 
the  command  "REPORT"#  e.g,#  REPORT  prog.mbr,  al¬ 
lows  one  to  scan  through  one's  program  on  the 
terminal.  More  importantly#  all  errors  detected 
by  the  compiler  are  flagged  with  their 
corresponding  diagnostic  message. 


A  typical  session  on  vax/vms  consists  of  the  following: 


1.  Code  and  compile  the  specification  file  for  the 
problem#  l.e,#  the  program#  at  hand,  since  a 
specification  file  is  essentially  just  a  means  of 
formalizing  in  ADA  what  one  considers  the  Inter¬ 
face  to  be#  It  usually  needs  no  environment  prag¬ 
ma  statement, 

2.  Code  and  compile  the  body#  which  is  the  means  by 
which  one  Implements  the  program.  Since  the  body 
depends  on  what  the  Interface  is#  the  environment 
file  representation  of  the  corresponding  specifi¬ 
cation  file  must  be  included.  Additionally#  if 
I/O  is  to  be  performed  in  the  body,  which  Is  gen¬ 
erally  the  case,  the  general  I/O#  Intel-supplied 
package  (TEXTIQ)#  must  also  be  included  In  the 
pragma  environment  statement. 


An  example  of  all  this  can  be  found  in  Appendix  C.  which 
shows  the  ADA  source  code  for  the  programs  dene  in  this 

thesis. 
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In  ease  It  wasn't  made  clear  In  the  above  discussions^ 
compilation  order  is  important*  Any  modules  included  in  the 
pragma  environment  statement  or  referenced  in  the  standard 
ADA  constructs*  "WITH..."  and  "USE..."  must  be  successfully 
compiled  beforehand*  otherwise  unsuccessful  comoilation  is 
all  the  reward  one  will  get  for  one's  efforts  in  the  current 
compilation  attempt. 

Successful  compilation  means  the  creation  of  three  new 
files  in  addition  to  the  original  source  file.  Directory 
space  in  VMS  is  gulcicly  exhausted  if  one  is  performing  many 
compilations.  Without  adequate  directory  space*  the  INTEL 
compiler  and  linker  will  abort.  Therefore*  when  asking  for 
an  account*  the  system  managers  must  be  informed  that  mere 
directory  space  than  Is  normally  given  a  VMS  user  is  needed. 
Furthermore*  in  an  attempt  to  provide  a  quick  means  of 
deleting  unneeded  environment*  object-code  listing*  and 
object-code  files*  the  commands*  mope,  mope*  and  mopo  will 
automatically  delete  all  files  of  the  corresponding  fiietyoe 
in  the  current  directory. 

Once  one  has  successfully  defined  one's  interface*  coded 
it*  compiled  it*  and  has  done  the  same  with  the 
corresponding  body  or  bodies*  one  has  reached  the  point 
where  in  most  traditional  systems  one  is  ready  to  link  the 
object  code  in  preparation  for  actual  program  execution.  In 
the  432  ease*  additional  compilation  must  still  ee  performed 
before  the  linking  process  may  begin. 
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First*  a  aodula  termed  PSERP.MBS  must  be  compiled.  An 
example  of  this  is  included  in  Appendix  C.  Its  function  is 
to  initialize  the  user  process(es).  It  essentially  marks 
which  module  is  to  begin  execution  first.  For  Instance,  a 
Driver  routine  which  Invokes  all  other  subroutines  is 
usually  executed  first.  In  our  case,  PSERP  always 
initialized  the  Driver  routine,  which  we  always  termed  MAIN, 
in  an  attempt  to  cut  down  on  our  coding/conollation  efforts. 
Secondly,  as  pointed  out  in  the  architecture  overview  on 
operating  system  support,  users  can  tailor  some  of  the  IHAX 
O.S.  packages.  In  this  thesis,  modification  of  the  system 
configuration  package,  PSORS.MBS,was  implemented.  Hence,  the 
successful  compilation  of  this  modified  package  was  also 
needed.  This  package  is  also  included  in  Apoendix  C. 

3.  LINKING 

The  «MSO  or  .MBO  files  produced  by  a  successful 
compilation  are  input  to  the  432  linker  by  being  listed  in  a 
user  created  directives  file.  The  output  from  a  successful 
link  Is  of  filetype  «E00.  EOO  stands  for  "External  object 
Description".  Actually,  the  respective  MSO  and  MBO  output 
files  from  the  compiler  are  in  this  EOD  format.  The  choice 
of  using  EOD  as  the  filetype  of  the  output  from  the  linker 
is  an  arbitrary  one. 

The  432  linker  combines  a  set  of  compiled  EOD's  (e.g. 
the  .MSO  and  .mbo  files)  into  a  single  linked  EOD,  Compiled 
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EOD's/  generated  by  tne  ACS»  contain  program  modules.  These 
modules,  in  turn,  contain  a  collection  of  compiler-generated 
objects,  such  as  segments,  refinements,  etc.  The  output  from 
the  llnKlng  process,  a  single  file.  Is  then  downloaded  to 
the  NDS  800  system. 

The  432  linker  performs  the  following  traditional 
functions: 


1.  Resolves  Inter-module  references. 

2.  Assigns  physical  memory  addresses  to  all  segments 
contained  In  the  Input  modules. 

3.  Verifies  the  compatibility  of  modules  that  are 
linked  together. 

4.  Produces  a  linked  EOO  that  may  be  loaded  into  the 
System  432/670  main  memory  and  executed, 

5.  <3enerates  error  messages  for  abnormal  conditions 
encountered  during  processing, 

6.  denerates  a  linker  listing  that  summarizes  the 
results  of  the  linker  operation  and  address  as- 
slonment. 


In  addition,  the  linker  performs  the  following  432-speelflc 
actions ; 


1.  Version  checks  the  input  EODs  for  compatibility, 

2.  Assigns  object  table  directory  Indices  and  object 
table  Indices  (known  as  object  coordinates)  for 
objects  contained  within  the  input  modules. 

3.  Builds  the  physical  432  access  segments  described 
symbolically  within  each  input  module, 

4.  Builds  object  tables  and  the  object  table  direc¬ 
tory  associated  with  the  objects  in  the  input 
modules. 


5.  Generates  Initialization  object  tables,  access 
descriptors,  and  storage  allocation  Information, 

The  net  result  of  all  this  Is  an  COD  which,  when  loaded 
Into  432  memory,  will  execute  as  one  has  programmed  It. 

The  input  or  directives  file  to  the  432  llnicer  should  be 
a  file  created  on  Vhs  with  a  file  extension  of  LKD.  This 
file,  an  example  of  which  Is  provided  in  Figure  21,  may  have 
other  file  extensions  or  types.  However,  If  that  Is  the 
ease,  then  the  full  file  name  must  be  given  to  the  linker, 
i.e,,  LKD  is  the  default  file  type.  For  example,  given  a 
link  file  which  we  call  "TEST, LKD" ,  to  link  this  file,  the 
following  command  would  be  entered: 

LINK432  TEST 

The  linking  process  can  be  appreciably  longer  than 
compilation.  However,  if  linkage  is  successful,  a  single, 
simple  message  of: 

LINKAGE  SUCCESSFUL 

Should  be  the  only  message  which  appears  on  the  console, 
warning  messages,  not  error  messages,  accompanied  by 
"LINKAGE  SUCCESSFUL",  do  not  really  mean  a  successful 
linkaget  At  least  this  has  been  true  in  our  experience,  A 
detailed  explanation  of  the  different  directives  which  can 
appear  in  the  linker  file,  plus  their  meanings,  can  be  found 
In  the  manual,  "VAX/vms  Host  user's  Guide",  with  the 


culmination  of  a  successful  llnicing#  one  is  ready  to 
download  the  output  file  generated  by  the  linicer  to  the  MDS 
800  system.  For  a  detailed  explanation  of  the  linking 
process  and  the  available  directives. i.e. .  commands  included 
in  the  linx  file,  refer  to  "VAX/vms  Host  User's  Guide". 


;  Ah  examole  of  a  llnX  file  which  serves  as  inout 
;  to  the  432  linker.  The  semicolons  which  precede 
;These  statements  signify  comments.  Link, free, 

:  outout, print,  and  objectmap  are  examples  of 
I  linker  directives.  The  blank  lines  which  occur 
;  between  directives  MUST  be  presenti 

link  ACS:lMAXvl.eod 
ACS:textlo.mio 
example!. mso 
examplel .mbo 
maln.nso 
maln.-'bo 
pserp.mbo 
osors .mbo 

freed  in  directory) 

output  example. eod 

print  example. mao 
objectmap 

This  could  be  filed  in  VMS  as  TEST.LKD 


mioure  21.  A  Linker  Input  File 


4.  DOWNLOADING 

Downloading  is  performed  on  the  MDS  800  system.  in 
order  for  downloading  to  be  accomplished,  the  VAX  must  be 
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operating  under  VMS.  A  cable,  marked  with  a  tag  which  reads 
"VAX",  Is  the  transmission  facility  for  downloading.  The 
following  steps  comprise  the  procedure  to  follow  when 
downloading  a  file: 


1,  Attach  the  VAX  cable  to  the  ADM36  terminal.  Logon 
to  VMS  as  you  normally  would.  Enter  the  following 
command  *  "SET  TERM/SPEEDb2400" ,  This  is  done  be¬ 
cause  the  MDS  800  system  Is  currently  modified  to 
supoort  only  2400  baud  communication  rates  unless 
hardware/software  changes  are  implemented. 

2,  Remove  the  VAX  cable  from  the  ADM  terminal,  con¬ 
nect  one  end  to  a  null  modem.  Connect  the  other 
end  of  the  null  modem  to  the  MDS  800  TTY  port  lo¬ 
cated  on  the  control  unit, 

3,  Insert  Into  drive  0  of  the  MDS  800  system  the 
ASYNCH  LINK  diskette. 

4,  Insert  into  drive  1  the  diskette  one  wishes  to 
download  to,  Root  the  system, 

5,  On  the  MPS  800  terminal,  enter  the  following  com¬ 

mand  s  "DNLOAD  <VMS  EOC  flle>  TO  :Fi;<new  or  same 
file  name>.  For  Instance,  assume  one  nas  an  EOD  • 
file  named  TEST.EOD  In  the  VMS  directory.  Furth¬ 
ermore,  one  wishes  to  call  this  file  TESTl.fCD  on 
the  MDS  800  system.  One  would  enter  the  following 
command:  "ONLOAD  TEST.EOD  j  TO 

:FUTESTl.EOD",  quotes  not  Included,  / 


we  have  experienced  average  download  times  of 
approximately  20  minutes.  Any  errors  in  transmission  mean 
that  downloading  must  be  redone  until  a  complete  error-free 
download  is  accomplished,  we  have  not  experienced  any  errors 
In  downloading  to  date.  The  conclusion  of  a  successful 
download  marks  the  beginning  of  the  next  step,  execution  on 
the  432. 
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5.  PROGRAM  LOAD/EXECUTZON 

Now  that  a  llnKed  EQD  flla  is  on  a  diskette,  all  that 
remains  Is  to  load  It  Into  432  memory  and  execute  It.  The 
following  procedure  assumes  that  the  MDS^  800  system  and  the 
432/670  execution  vehicle  are  powered  up  and  have  no 
hardware  faults.  In  the  following  /discussion,  commands  which 
are  to  be  entered  at  the  mds  800  terminal  (termed  the 
"debugger  console"  by  INTEL)  will  be  printed  in  capital 
letters  and  enclosed  In  quotes.  This  Is  for  illustration 
purposes  only.  Capital  letters  are  not  necessary,  and  quotes 
will  result  in  an  error  message. 


1.  Insert  into  drive  0  of  the  MDS  800  system,  the 
diskette  labeled  UPDATE-432/DEBUG-432 . 

2*  Insert  Into  drive  1  the  diskette  which  contains 
the  executable  program.  Boot  the  system. 

3.  Enter  the  following  command:  "run  work  :fO!". 

4.  When  the  ISIS  prompt  (•)  returns,  enter:  "RUN 
DEB432".  This  should  result  in  the  display  of 
"SERIES  III  432  Systems  Level  Debugger,  vi.OO". 

5.  Once  'in  the  debugger'  the  ISIS  prompt  will  be 
replaced  by  a  "?"  as  the  prompt  symbol.  Enter  the 
command:  "INIT". 

6.  When  the  prompt  returns,  enter:  "INCLUDE 

0EB432,TEM". 

7.  When  the  prompt  returns,  enter:  "DEBUG  :Fl:< 
f llename.f iletype  >".  For  example,  suppose  one 
has  downloaded  the  file  TEST.EOD  which  one  wishes 
to  execute.  Here,  one  would  enter:  "DE'fUG 
trilTEST.EOD". 

8.  Enter:  "START",  This  command  Initiates  program 
execution. 


147 


This  command  will  result  in  program  execution  on  the 
432*  For  an  in*depth  explanation  of  debugging  facilities 
available  on  the  432,  in  case  the  program  does  not  execute 
as  planned,  refer  to  "Worxstation  User's  Guide", 
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